Nexus Framework: Scaling Scrum for 3 to 9 Teams

By Tara Minh · Updated Oct 10, 2026

Nexus is a framework from Scrum.org for approximately three to nine Scrum Teams working together on one product. It keeps Scrum's rules and adds only what's needed to manage dependencies: a Nexus Integration Team, a few extra events, and one shared Integrated Increment that every team contributes to each Sprint.

Most scaling pain isn't about writing code faster. It's about two teams touching the same module, a third waiting on both, and nobody noticing until the end of the Sprint. Nexus is built around that problem. It doesn't ask you to restructure the company. It asks you to make dependencies visible early and give someone clear responsibility for integration.

Key Facts

• Nexus was developed by Ken Schwaber and Scrum.org, and the Nexus Guide has had editions in 2015, 2018 and 2021.
• The current Nexus Guide (January 2021) describes a Nexus as approximately three to nine Scrum Teams with one Product Owner and one Product Backlog.
• The Nexus Integration Team is made up of the Product Owner, a Scrum Master, and one or more Nexus Integration Team Members.
• The guide gives no fixed timeboxes for Nexus events. Their durations are guided by the matching Scrum events.
• The 2021 edition renamed Refinement to Cross-Team Refinement.
• LeSS covers 2 to 8 teams, so the two frameworks overlap heavily on team count and differ mainly in how much organizational change they ask for.

What is the Nexus framework?

Nexus is a framework for developing and sustaining scaled product delivery. It extends Scrum minimally. Teams still run Sprints, keep a single Product Owner and Product Backlog, and answer to the same Scrum values. What changes is that the group produces one Integrated Increment instead of several loosely related ones, and a small group takes accountability for making that integration happen.

The word "nexus" means a connection point, and the framework is mostly about connections: between backlog items, between teams, and between the work each team calls Done and what actually ships together.

Three ideas carry most of the weight:

• One product, one backlog. All teams pull from the same Product Backlog, owned by one Product Owner.
• Dependencies are the enemy of flow. Refine them out before the Sprint, and track the ones that remain.
• Integration happens every Sprint. The Nexus must produce a working, integrated Increment at least once per Sprint, not at the end of a release phase.

Nexus roles: the Nexus Integration Team

Nexus adds no new management layer. It adds one team. According to the Nexus Guide, the Nexus Integration Team includes:

The common misreading is that the Integration Team does the integrating. It doesn't. Each Scrum Team still does its own integration work. The Integration Team coordinates, coaches, and removes obstacles, and it's accountable for the Integrated Increment actually existing and meeting the Definition of Done. It also owns the shared Definition of Done for the Integrated Increment. Individual teams can hold themselves to a stricter standard, but not a looser one.

Membership can rotate as the work changes. The guide says a person's place on the Integration Team takes precedence over their team membership as long as the Integration Team's responsibilities are met, which is a polite way of saying the role comes first when the two conflict.

Nexus events

Nexus keeps the standard Scrum events and wraps them with cross-team versions. Here's how each one works according to the Nexus Guide.

A few practical notes on how these play out:

Cross-Team Refinement is the event that earns its keep. If your teams spend Sprint Planning discovering that Team B needs a schema change from Team A, refinement failed. Treat it as continuous work, closely related to ordinary backlog refinement but with the specific job of spotting and shrinking cross-team dependencies.

Nexus Sprint Planning is where representatives from the teams meet to confirm the order of work and the team assignments, then each team does its normal sprint planning on its own slice. The Nexus Sprint Backlog that comes out of it is the shared view of everything in play.

The Nexus Daily Scrum is for representatives, not everyone. It's short, it's about integration, and its output is adjustments to the Nexus Sprint Backlog and the teams' own plans.

Nexus artifacts

Nexus uses the Scrum artifacts and adds a couple of shared versions:

The guide used the term "Nexus Goal" in earlier editions and renamed it Nexus Sprint Goal in 2018, to match Scrum's wording. If you read older blog posts, expect the older term.

Nexus vs SAFe, LeSS, Scrum of Scrums and Disciplined Agile

Nexus sits in the lighter half of the scaling spectrum. Here's how it compares with the options people usually weigh against it.

Two comparisons deserve a sentence each. Against SAFe, Nexus is the smaller commitment: you don't adopt a planning cadence for the whole enterprise, you add one coordination team to teams that already share a product. Against LeSS, the difference is how much you're willing to reorganize. LeSS asks for feature teams and a single Product Owner with real authority across everything, while Nexus assumes you already have those basics and need help with the integration seams.

Scrum of Scrums is the lightest option of all. It's a recurring meeting where team representatives share dependencies, and it's often what teams do before they adopt anything formal. Nexus can be read as a more structured version of that idea, with defined events, artifacts and an accountable group behind it.

How to start using Nexus

Here's a sequence that fits how teams usually adopt it.

1. Confirm the prerequisites. You should have three or more teams building one product, one Product Owner, and teams that can already run a decent Sprint on their own. Nexus won't fix a team that doesn't do Scrum yet.
2. Form the Nexus Integration Team. Name the Product Owner, pick a Scrum Master, and choose one or two experienced people from the teams as Integration Team Members. Agree what you expect of them in a short working agreement.
3. Write one shared Definition of Done. Make it cover integration, not just team-level completion, so "Done" means it works with everything else.
4. Start Cross-Team Refinement. Pick a regular slot each week. Walk the top of the backlog, mark dependencies, and slice items until most can be finished by one team.
5. Run Nexus Sprint Planning. Choose a Nexus Sprint Goal, assign items to teams, and build the Nexus Sprint Backlog with the remaining dependencies visible.
6. Keep a dependency board. Use the template below and review it in the Nexus Daily Scrum.
7. Hold a single Nexus Sprint Review and Retrospective. Show one Integrated Increment, not five demos, and improve how the teams work together.
8. Inspect and adjust. If integration problems keep showing up late, fix refinement first, then team composition.

Template: cross-team dependency board

Copy this into your tracker and update it every day. It's the artifact people ask for most when they start with Nexus.

Column notes:

• Needs from / Needed by keeps the direction of the dependency explicit. Without it, boards turn into lists of worries.
• Needed by date should be a Sprint day, not a vague "soon." This is what gets reviewed in the Nexus Daily Scrum.
• Status only needs four values: Not started, In progress, Blocked, Done.
• Risk if late gives the Integration Team a quick ranking for what to chase first.

A good habit is to count the open rows at Nexus Sprint Planning and again after Cross-Team Refinement. If the number isn't dropping from Sprint to Sprint, refinement is not removing dependencies and the team structure is the next suspect.

Examples by function

Nexus came out of software, but the mechanics apply to any product made by several teams working in Sprints.

Do's and don'ts

When Nexus is the wrong choice

Nexus is the wrong fit if you have fewer than three teams, because Scrum plus a light sync is enough. It's also the wrong fit if you're coordinating many unrelated products rather than one, or if your teams haven't yet made single-team Scrum work. And if you need portfolio funding, enterprise planning and heavy governance, a framework like SAFe covers more ground. Nexus gets you from three teams to nine. It doesn't pretend to be an operating model for a whole company.

If your teams already run Scrum and keep stumbling over each other near the end of the Sprint, Nexus is a small, low-risk change: name an Integration Team, start refining for dependencies, and review one Integrated Increment together. Start there, and only add structure when the board tells you it's needed.