Nexus
A framework from Scrum.org that extends Scrum for 3-9 teams building a single product, adding a Nexus Integration Team to resolve cross-team dependencies.
What it is
Nexus was created by Ken Schwaber and Scrum.org as a minimal extension to Scrum for multiple teams. Unlike larger scaling frameworks, Nexus adds only what is strictly necessary to coordinate teams working on a single product.
The central addition is the Nexus Integration Team (NIT). This is not a separate delivery team — it is a group of representatives from each Scrum team plus the Product Owner, whose sole accountability is ensuring a Done, integrated Increment is produced every Sprint.
The NIT exists to ensure integration, not to supervise teams. Members may contribute to the codebase when integration work is required, but their primary role is coaching, supporting, and removing integration-level impediments.
When to use it
| Use Nexus when… | Consider alternatives when… |
|---|---|
| You have 3–9 Scrum teams on a single product | You have fewer than 3 teams (use single-team Scrum) |
| Integration is your primary scaling challenge | Your teams work on entirely separate products |
| You want a Scrum-aligned framework with minimal overhead | You need extensive portfolio or program-level governance |
| Your teams already practice Scrum competently | Your teams are new to Scrum itself |
Key concepts
Nexus Integration Team
The NIT comprises the Product Owner, a Scrum Master, and representatives from each Scrum team. It is accountable for a Done, integrated Increment every Sprint — not for assigning work or tracking progress.
Nexus Sprint Planning
Planning happens in two parts. First, all teams meet to identify dependencies and order the work across the Nexus. Then each team conducts its own Sprint Planning, informed by the cross-team view.
Nexus Daily Scrum
Appropriate representatives from each team meet daily to surface integration issues and cross-team dependencies. This is not a status report — it is a problem-identification forum.
Nexus Sprint Review
All teams present their work together as a single integrated Increment. Stakeholders see the whole product, not siloed team updates.
Nexus Sprint Retrospective
Three-part structure: each team holds its own retrospective, then representatives meet for a Nexus-wide retrospective, then each team adapts based on shared findings.
Common pitfalls
| Pitfall | Why it happens | How to avoid it |
|---|---|---|
| Treating the NIT as a supervisory layer | Management is uncomfortable without hierarchy | Reinforce that the NIT coaches and integrates, not manages |
| Allowing separate backlogs per team | Teams want local control | Maintain one Product Backlog for the entire Nexus |
| Not producing an integrated Increment | Integration is deferred to "later" | Make integration a first-class activity every Sprint |
| Skipping Nexus events | Teams are busy with their own work | Treat Nexus events as non-negotiable; they exist to reduce waste |
| Adopting Nexus before single-team proficiency | Desire to scale quickly | Ensure each team can deliver a Done Increment independently first |
NZ context
In the New Zealand market, Nexus often represents a pragmatic middle ground. Companies that find single-team Scrum too limiting but recoil from the complexity of SAFe frequently land on Nexus as a sensible step up.
NZ consultancies and mid-size product companies with 4–6 teams often adopt Nexus because it provides just enough structure to manage dependencies without requiring a full transformation office or release train.
Career level guidance
| Level | What to know | What to demonstrate |
|---|---|---|
| Junior | Understand that Nexus is Scrum for multiple teams | Can explain the role of the Nexus Integration Team in plain language |
| Intermediate | Know the Nexus events and how they relate to Scrum events | Can participate effectively in Nexus Sprint Planning and Daily Scrum |
| Senior | Understand dependency management and integration accountability | Can represent their team in the NIT and coach others on cross-team coordination |
| Test Lead / QA Lead | Understand what a Done, integrated Increment means for quality | Can design integration test strategies and ensure quality gates are met across teams |