Nexus

One addition, deliberately

Nexus starts from a specific diagnosis. When three to nine Scrum teams work on one product, the first thing to break is usually not the coordination of plans — teams can generally talk to each other and divide work up. What breaks is the integration of the work. Code that was fine in isolation stops being fine when it meets the other eight teams' code, and by the time anyone finds out, the sprint is over.

So Nexus adds one accountability and stops. Everything else stays exactly as the Scrum Guide describes it: one Product Owner, one Product Backlog, one Product Goal, one Sprint of the same length for everyone, and each team running its own Sprint Planning, Daily Scrum, Review and Retrospective. The word "Nexus" simply means the connection between the teams and the dependencies between their work.

Who is on the Integration Team

This is the part of Nexus most often misread, and the mistake is baked into the name. "Integration Team" sounds like a separate squad that merges everyone's branches. It is not. The Nexus Integration Team is accountable for ensuring that a Done, integrated Increment is produced at least once every Sprint — accountable for it happening, not for doing it.

• The Product Owner

  The same single Product Owner who owns the whole Product Backlog. Sitting on the Integration Team is what keeps ordering decisions connected to integration reality, instead of a backlog order that is technically impossible to deliver together.

• A Scrum Master

  One Scrum Master with accountability for the Nexus working as a whole. They may also serve one of the Scrum teams, but the Nexus-level accountability is theirs and cannot be spread across everyone.

• Integration Team Members

  Practitioners drawn from the Scrum teams themselves — usually the strongest people on tooling, architecture, testing and the deployment pipeline. Membership is not permanent and changes as the integration problem changes.

The members keep working on their own teams. That is the design: a person who spends part of the week on integration concerns and the rest building features carries the standard back into their team rather than becoming a gatekeeper for it. The Guide is explicit that the work of the Integration Team is coaching, consulting and raising awareness — teaching teams to produce integrable work, not integrating on their behalf.

Three artefacts, three commitments

Nexus keeps Scrum's artefact-plus-commitment pairing and adds one artefact of its own. Each artefact answers a different question, and the commitment attached to it is what stops the artefact drifting into a status report.

The Nexus Sprint Backlog deserves attention because it is the only genuinely new artefact. Its purpose is not to be a bigger to-do list — it is a dependency view. Teams look at it to see which of their items depend on another team's item and when that item is expected, which is the information that makes the difference between finding a dependency on day two and finding it on day nine.

The Definition of Done is where Nexus is strictest. There is one Definition of Done for the Nexus, defined by the Integration Team, and every Scrum team must meet at least it. A team may apply a stricter one for its own work; it may never apply a looser one. Without that single standard, "integrated" means a different thing in each team and the Integrated Increment is not integrated in any meaningful sense.

The Nexus events

Each Scrum event gains a Nexus-level counterpart that wraps around it. None of them replace the team-level events — the teams still run their own — and none of them are status meetings. Every one of them exists to surface a dependency or an integration problem earlier than it would otherwise appear.

Cross-Team Refinement

This is the event that carries the most weight and gets skipped the most. Its job is to take Product Backlog items that are still too coarse and break them down until it is clear which team will do which piece — and until the dependencies between those pieces have been removed where possible and made explicit where not. Refinement in Nexus is not an estimation ritual; it is dependency demolition performed before the sprint starts.

Nexus Sprint Planning

Appropriate representatives from each team meet with the Product Owner to review the refined backlog and agree how the work is distributed. The output is a single Nexus Sprint Goal that describes the purpose of the whole Sprint across all teams. Each team then holds its own Sprint Planning and forms its own Sprint Goal, which must be consistent with the Nexus one.

Nexus Daily Scrum

Representatives from each team — usually developers close to the integration work, not managers — meet before the team dailies. They inspect the current Integrated Increment for problems, and identify integration issues and newly discovered dependencies. What they find is then carried into each team's own Daily Scrum, which is why the ordering matters.

Review and the three-part Retrospective

The Nexus Sprint Review replaces the individual team reviews rather than adding to them. There is one review, of one Integrated Increment, with stakeholders — because nine separate demos of unintegrated parts tell stakeholders nothing about whether the product works.

The Retrospective runs in three parts, and the shape is the point. First, representatives meet to identify issues that affect more than one team. Then each team holds its own Retrospective, using those shared issues as input alongside its own. Finally the representatives meet again to agree what will actually be done about the shared ones. Without the third part, cross-team problems get discussed every sprint and fixed in none.

Choosing between the scaling frameworks

Nexus is the smallest step up from single-team Scrum, which makes it the right first move for most organisations that have just outgrown one team. If it stops working past nine teams, that is the signal to look at LeSS Huge or SAFe — not before. Scrum.org describes running several Nexuses against one product for larger cases, but deliberately publishes no detailed prescription for it, which is a fair sign that this is the edge of the framework rather than its intended territory.

How this shows up in real delivery

Nexus only pays off if the Integrated Increment is real. That means a shared pipeline, a shared Definition of Done and integration happening at least daily. A Nexus without continuous integration is a set of meetings that discovers the same integration debt one sprint later than it would have anyway — and it will be blamed on the framework rather than on the missing pipeline.

Where it degrades

• The Integration Team doing the merges instead of coaching teams to integrate their own work.
• A per-team Definition of Done, so "integrated" means different things in different teams.
• Skipping Cross-Team Refinement, which pushes dependency discovery into the sprint.
• Nine separate Sprint Reviews instead of one review of the integrated product.
• Sending managers to the Nexus Daily Scrum, which turns a working session into a status round.
• Dropping the third part of the Retrospective, so shared problems are named every sprint and fixed in none.

When to use it

Related pages

• ManagementScrumScrum is the most widely used way of organising a software team. Scrum breaks work into short, fixed cycles called sprints, gives three people clear areas of responsibility, and puts a small set of regular meetings around the work so problems surface within days instead of months. This page walks through every one of those meetings — including several that real teams hold but the official guide never mentions.
• ManagementLeSSLeSS — Large-Scale Scrum — keeps one Product Owner, one Product Backlog, one Sprint and one shippable Increment, no matter how many teams. It scales by removing organisational structure rather than adding it, which makes it the most demanding scaling framework to adopt and the closest to actual Scrum. This page covers the ten principles, the rules-guides-experiments layering, every LeSS event, and both variants.
• ManagementScrum@ScaleScrum@Scale is Jeff Sutherland's scaling framework, built on two linked cycles — one for what gets built, one for how — that repeat fractally at every level. It is modular rather than configured: you adopt the components your bottleneck requires and leave the rest alone. This page lists every component of both cycles, the two points where they touch, and the roles and events each one adds.