Nexus
Origin
Ken Schwaber, co-creator of Scrum, developed Nexus based on the observation that the main problems when scaling Scrum were not about process but about integration: multiple teams producing code that has to be combined at the end of the sprint. The first version of the Nexus Guide was published in 2015 on scrum.org.
Structure
The Nexus Integration Team
The distinguishing element of Nexus is the Nexus Integration Team (NIT): a team responsible for ensuring that the work of all the Scrum Teams is properly integrated in every sprint. The NIT does not replace the teams; it supports them in resolving technical integration issues.
It is usually made up of the Product Owner (shared across all teams), a Scrum Master, and people with technical integration skills. NIT members may also belong to individual Scrum Teams.
Nexus Events
Nexus adds events to the standard Scrum cycle:
- Nexus Sprint Planning: before each team's individual planning, the teams coordinate dependencies and select which parts of the backlog each one will take on.
- Nexus Daily Scrum: a brief daily synchronization for team representatives, focused on identifying and resolving integration impediments.
- Nexus Sprint Review: the teams jointly present the integrated increment to the stakeholders.
- Nexus Sprint Retrospective: in three phases — representatives from all teams identify integration issues, each team holds its own individual retrospective, and everyone together agrees on improvement actions.
The Nexus Sprint Backlog
A view of the sprint's stories that helps visualize dependencies between teams and identify where integration problems may arise.
When to use Nexus
Nexus is appropriate when a single Product Owner manages a product that requires more capacity than one Scrum Team can provide. If the product can be broken down into truly independent components managed by different teams, Nexus may not be needed.
Nexus vs. SAFe
Nexus is lighter than SAFe: it does not prescribe portfolio or solution levels, it has no additional roles beyond the NIT, and it assumes that teams already know Scrum. It is the most suitable option when the problem is one of technical integration between teams, not strategic alignment at an organizational scale.
Common mistake
Using Nexus without first resolving the technical dependencies between teams. Nexus manages dependencies; it does not eliminate them. If the system design leaves teams tightly coupled to one another, the Nexus Daily Scrum and the NIT will be constantly busy clearing blockers. Investing in an architecture that reduces dependencies between teams is more productive than adding coordination events on top of a highly coupled system.
References
- Schwaber, Ken; Caña, Patricia. (2021). The Nexus Guide. Scrum.org. nexusguide.org.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.