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 |
Industry Reality
- Most organisations adopting Nexus keep the NIT label but quietly repurpose it as a de-facto architecture or planning committee — the "integration accountability" framing gets lost within a quarter.
- A shared Product Backlog is written into the framework guide but few organisations sustain it; teams tend to re-establish informal sub-backlogs for their own roadmap comfort, especially under pressure from siloed product managers.
- The Nexus Daily Scrum is the first event to be skipped when Sprint pressure mounts — senior practitioners treat attendance as a health signal and treat consistent no-shows as an early warning of integration risk.
- In NZ, Nexus is frequently adopted by mid-size companies (50–200 staff) that want structure without a full SAFe rollout; it is rarely adopted wholesale — most blend it with existing practices and keep only the NIT and joint Sprint Review.
- Integration test automation is the make-or-break factor. Teams that do not have a reliable, fast integration suite typically cannot produce a truly Done Increment by Sprint end, regardless of how well they follow the Nexus ceremonies.
Context guide
How the right level of Nexus effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| HealthNZ / HealthNZ digital transformation — 5+ Scrum teams rebuilding shared patient record infrastructure under the Pae Ora Act | Essential | Integration failures in health systems carry patient-safety consequences; a formally accountable NIT that owns the integrated Increment every Sprint is non-negotiable at this scale. |
| Revenue NZ running 4 Scrum teams on a single tax-platform codebase after the START programme, sharing one CI/CD pipeline | Essential | A shared pipeline with four teams merging independently creates integration race conditions; Nexus Daily Scrum and the NIT give a structural owner for merge discipline and cross-team smoke failures. |
| Pacific Bank digital banking product with 3 Scrum teams where regulatory audit (RBNZ prudential standards) requires a demonstrable integrated release each Sprint | High | The joint Sprint Review and NIT's integration accountability map cleanly to audit evidence requirements; easier to demonstrate a Done integrated Increment than to piece together three separate team demos. |
| TeleNZ product squad with 3 Scrum teams building a new broadband self-service portal, moderate dependency overlap on a shared API layer | High | Shared API contracts break silently across teams; Nexus Sprint Planning part one and a rotating NIT representative catch contract drift before it becomes a Sprint-end emergency. |
| A Wellington-based SaaS startup with 2 Scrum teams on separate microservices that communicate via well-documented stable APIs | Medium | Nexus is designed for 3-9 teams; with only 2 and stable contracts, a lightweight Scrum of Scrums meeting costs less than standing up a full NIT. Revisit when a third team joins. |
| CoverNZ running 5 teams delivering independent insurance-product modules to separate business units with no shared codebase or deployment pipeline | Low | Nexus solves integration dependency; where there is no genuine shared Increment, the NIT and Nexus events add ceremony without benefit. Independent teams should remain independent. |
Trade-offs
What you gain and what you give up when you adopt Nexus.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Formal integration accountability — the NIT owns the Done integrated Increment, eliminating the "whose problem is it?" conversation at Sprint end | NIT membership overhead — rotating senior engineers off their team each Sprint costs delivery capacity; poorly managed rotations create a permanent senior-engineer bottleneck | You have fewer than 3 teams: single-team Scrum with a shared Definition of Done achieves the same outcome at far less ceremony cost |
| Scrum-aligned with minimal conceptual overhead — teams already fluent in Scrum can adopt Nexus without learning a new methodology or role set | Single Product Backlog discipline is hard to sustain — under delivery pressure, product managers re-establish informal team backlogs, undermining Nexus Sprint Planning part one | Your teams are new to Scrum: add Nexus before teams master single-team Scrum and you compound ceremony debt with coordination debt simultaneously |
| Joint Sprint Review gives stakeholders a single, whole-product demonstration rather than siloed team updates — reduces context switching and makes interdependencies visible | No portfolio or programme governance — Nexus has no equivalent of SAFe's PI Planning or Agile Release Train; organisations that need value-stream-level prioritisation must supplement it separately | You need enterprise-level governance spanning multiple products or business units: SAFe or LeSS Huge covers value streams, budgeting, and architecture governance that Nexus deliberately omits |
| Three-part Retrospective structure ensures systemic issues surface at the Nexus level before individual teams solve them in isolation — avoids duplicate remediation efforts | Integration engineering investment is a prerequisite, not an outcome — Nexus ceremonies cannot produce a Done integrated Increment without shared build pipelines and automated cross-team test suites already in place | Your teams are independently deployable and decoupled: a lightweight Scrum of Scrums meeting costs less and achieves equivalent coordination without the NIT overhead |
Enterprise reality
How Nexus changes when you have 200–300 developers across 10+ squads — in NZ banks, government agencies, and telcos, the framework looks very different from a five-team startup.
- The Nexus Integration Team's manual dependency-mapping work is largely replaced by automated dependency graphs generated from CI/CD tooling — Atlassian Jira's Dependency Report or Azure DevOps delivery plans feed the Nexus Daily Scrum instead of post-it boards, because at 15+ teams the surface area of cross-team dependencies is too large to track by hand.
- Revenue NZ's START programme (one of NZ's largest public-sector digital transformations) required every integrated Increment to satisfy NZISM security controls and the Privacy Act 2020 before it could enter the shared integration environment — meaning the NIT's Definition of Done included automated compliance gate checks, not just functional test results. Skipping or deferring these gates at Sprint end triggered mandatory remediation sprints, costing weeks of delivery capacity.
- At NZ bank scale (Harbour Bank, Pacific Bank, KiwiFirst Bank), shared integration environments are subject to change-freeze windows enforced by RBNZ prudential standards and PCI DSS audit requirements — teams cannot simply merge to the integration branch at will, and the NIT must coordinate a weekly merge schedule that aligns with approved change windows, adding a governance layer that simply does not exist in smaller Nexus implementations.
- Coordinating Nexus ceremonies across 10+ squads in multi-timezone programmes (common in NZ organisations with Wellington, Auckland, and offshore India or Philippines teams) requires asynchronous Nexus Daily Scrum formats — integration dashboards with automated alerts replace synchronous stand-ups, and the NIT Scrum Master's role becomes as much about tooling configuration and Confluence/Slack integration as it is about facilitation. Teams that try to run synchronous Nexus events across a four-hour timezone gap routinely see ceremony attendance drop below 50% within two Sprints, destroying the integration visibility Nexus depends on.
◆ What I would do
Professional judgment — when to adopt Nexus, when to adapt it, and what to watch for.
The bottom line: Nexus is an integration accountability framework — it succeeds or fails based on whether the NIT genuinely owns the Done integrated Increment every Sprint, not on whether all the events are running on schedule. Fix the accountability first; the ceremony will follow.
Best Practices
- ✓ Rotate NIT membership every 2–3 Sprints so integration knowledge spreads across all teams rather than concentrating in a permanent "integration squad."
- ✓ Define "integrated" explicitly before Sprint 1 — agree on what test environments, API contracts, and data states must be in place for an Increment to be considered Done at the Nexus level.
- ✓ Visualise cross-team dependencies on a shared board (physical or digital) and review it at the start of every Nexus Daily Scrum, not just during Sprint Planning.
- ✓ Keep the Nexus Sprint Planning part-one timebox ruthlessly short — identify dependencies and high-risk interfaces only; detailed team-level planning belongs in part two.
- ✓ Run the Nexus Sprint Retrospective before individual team retros so that systemic issues can be fed down to team-level action items, not the other way around.
- ✓ Treat the Nexus Integration Team as a coaching resource — senior practitioners from each team should be empowered to refactor integration-breaking code, not just raise issues.
- ✓ Automate integration builds so every merge to the shared branch triggers a cross-team smoke suite; make the build status visible to all teams in real time.
- ✓ When teams are new to Nexus, hold a brief "dependency pre-mortem" at the start of Sprint Planning: ask what could prevent a shared Increment and assign explicit owners to each risk.
Common Misconceptions
❌ Myth: The Nexus Integration Team is a management layer that tells other teams what to do.
Reality: The NIT has no authority over individual Scrum teams' internal work. Its sole accountability is the integrated Increment. NIT members coach, remove integration impediments, and contribute to integration code — they do not assign tasks, approve stories, or review team-level velocity.
❌ Myth: Nexus requires each team to have its own Product Backlog.
Reality: Nexus mandates a single Product Backlog for the entire scaled product. Teams pull from that shared backlog during Nexus Sprint Planning. Separate team backlogs are explicitly against the framework and are one of the most common causes of diverging roadmaps and integration failures.
❌ Myth: Nexus is only relevant once you have 9 teams — small organisations don't need it.
Reality: Nexus is designed for 3–9 teams, and the dependency and integration challenges it addresses appear as soon as you have 3 teams sharing a codebase or product. Many NZ organisations benefit from Nexus patterns — particularly the NIT concept and joint Sprint Review — when they have as few as 3 teams working on the same product.
Senior engineer insight
The teams who thrive with Nexus treat the Nexus Integration Team as a temporary scaffold — one that ideally makes itself redundant by embedding integration thinking into every team's daily practice. Those who struggle typically appoint a permanent NIT of senior engineers who gradually become the de-facto architecture board, which is the exact antipattern Nexus is designed to prevent. The pattern that actually works: rotate NIT membership every 2–3 Sprints and publish a shared integration dashboard that every team owns and monitors, not just the NIT.
The most common mistake: treating Nexus Sprint Planning part one as a status meeting where teams report their plan rather than a dependency-mapping session where cross-team risks are actively negotiated and assigned owners before a single Sprint Backlog item is committed to.
From the field
A Wellington-based insurance platform with five Scrum teams adopted Nexus after their quarterly release cycles kept slipping — three teams would finish Sprint work but the integration environment was always broken when they tried to assemble a release. The NIT was formed, ceremonies were added, and for two Sprints nothing changed: the integration environment still broke on Friday afternoons because teams were merging independently all week and nobody owned the shared pipeline. The turning point was a simple rule the NIT introduced in Sprint 3 — every merge to the integration branch triggered an automated cross-team smoke suite visible on a shared Slack channel, and no team could merge after 2pm Thursday without NIT sign-off that the suite was green. Within a Sprint, late-breaking integration failures dropped by two-thirds. The lesson that travels: Nexus ceremonies create the coordination rhythm, but it is the shared automation and merge discipline that actually produces a Done integrated Increment — the events are worthless without the engineering practice underneath them.
Why teams fail here
- Teams adopt Nexus ceremonies without the integration engineering — no shared build, no automated cross-team smoke suite, no merge policy — so the NIT can only coordinate failures it cannot prevent.
- The NIT is staffed with senior engineers who never rotate, turning it into a permanent architecture review board that undermines team autonomy and becomes a Sprint-end bottleneck.
- Teams maintain informal sub-backlogs alongside the shared Product Backlog, so Sprint Planning part one surfaces only a subset of real dependencies and integration surprises accumulate until the final days of the Sprint.
- The Nexus Daily Scrum devolves into a status round-robin from each team's representative rather than a dependency and integration blocker triage, making it indistinguishable from a Scrum of Scrums meeting and eliminating the accountability advantage Nexus is supposed to provide.
Key takeaway
Nexus done well is not more Scrum meetings — it is the discipline of treating integration as a daily engineering accountability, not a Sprint-end assembly problem.
Self-Check
Click each question to reveal the answer.
Q: You are a QA lead at a NZ government agency running five Scrum teams building the next generation of the RealMe identity platform. Three teams are regularly missing the integrated Increment by Sprint end, citing dependencies on the other two teams. What Nexus mechanisms would you use to address this, and how would you change the team's behaviour?
A: This is exactly what the Nexus Integration Team (NIT) and Nexus Daily Scrum exist to solve. First, ensure the NIT has active representatives from each of the five teams — their job is to surface and resolve cross-team dependency blockers daily, not wait until Sprint Review. Second, use Nexus Sprint Planning part one to explicitly map dependencies before teams commit, so no team starts work that relies on another team's incomplete output. Third, treat the NIT's accountability for a Done, integrated Increment as non-negotiable — if integration keeps failing, that is a signal the NIT needs to invest in shared integration test automation rather than coordinating manually.
Q: Your organisation is running four teams on a KiwiSaver provider platform and is deciding between Nexus and Scrum of Scrums. What is the key structural difference between them, and which would you recommend and why?
A: The key difference is accountability and formalism. Scrum of Scrums is a coordination meeting — it has no formal accountability structure, no defined team composition, and no requirement to produce an integrated Increment. Nexus is a framework that adds a formally accountable body (the Nexus Integration Team) and prescribes specific events (Nexus Sprint Planning, Nexus Daily Scrum, joint Sprint Review, three-part Sprint Retrospective). For a KiwiSaver platform where integration failures have regulatory and financial consequences, Nexus is the stronger choice because it explicitly owns integration as an accountability, not just a coordination topic. Scrum of Scrums is lighter but leaves integration ownership ambiguous.
Q: When would Nexus be the wrong choice, even if you have 4–6 Scrum teams?
A: Nexus is the wrong choice when the teams are not yet proficient at single-team Scrum — the framework assumes each team can already deliver a Done Increment independently. It is also inappropriate when teams are working on entirely separate products or services with no shared codebase or deployment pipeline, since there are no genuine integration dependencies to manage. Additionally, if your organisation needs portfolio-level governance, program increment planning across multiple value streams, or enterprise architecture oversight, Nexus does not provide those capabilities — SAFe or LeSS would be more suitable. Forcing Nexus on teams that are not integration-coupled simply adds ceremony without benefit.
Q: A delivery manager says "The Nexus Integration Team is perfect — we can use it as the senior team to review and approve what the other teams build before release." What is wrong with this interpretation, and how do you correct it?
A: This is a fundamental misreading of the NIT's role. The NIT has no authority to approve, reject, or supervise the internal work of other Scrum teams — doing so would make it a management layer and undermine each team's self-organisation. The NIT's sole accountability is ensuring a Done, integrated Increment is produced every Sprint: it coaches, removes integration-level impediments, and contributes to integration code when needed. Using it as a quality gate or sign-off committee introduces a bottleneck, damages team autonomy, and is explicitly contrary to the Nexus framework. A better framing for the delivery manager: the NIT holds integration accountability so that stakeholders always see a working whole-product at Sprint Review — that is its value, not gatekeeping.
Prerequisites
Related Techniques
What to Learn Next
How this has changed
The field moved. Here is how Nexus evolved from its origins to current practice.
Nexus created by Ken Schwaber at Scrum.org — extend Scrum to 3-9 teams with minimal additional process. Adds one role (Nexus Integration Team), one artefact (Nexus Sprint Backlog), and integration events to standard Scrum.
Nexus published publicly and the Scaled Professional Scrum (SPS) certification launched. Positioned as the simplest way to scale Scrum — teams that know Scrum can adopt it without learning a new methodology.
Nexus 1.2 published with clarifications on the Nexus Integration Team role and the relationship between team-level DoD and the integrated increment.
The Scrum Guide 2020 update emphasises that Scrum is intentionally incomplete — teams combine it with complementary practices. Nexus positions itself as the complementary framework for Scrum teams that must integrate work across multiple teams.
Nexus occupies a niche between Scrum and SAFe — teams that want to scale Scrum without abandoning Scrum's principles. Its simplicity is its differentiator; organisations with complex dependencies may need more structure.