Nexus Framework: Scaling Scrum Explained (2026)

The Nexus framework is a lightweight way to scale Scrum, created by Ken Schwaber and Scrum.org. It brings 3-9 Scrum Teams together on one product, with one Product Backlog and one Product Owner. A Nexus Integration Team keeps cross-team dependencies visible and makes sure all teams deliver a single, working Integrated Increment at least once every Sprint.

Key Highlights of Nexus Framework

• Nexus keeps Scrum intact and adds only a few things: one new accountability, five events, and expanded artifacts.
• It is designed for roughly 3-9 Scrum Teams working from a single Product Backlog.
• The Nexus Integration Team (NIT) is accountable for a done Integrated Increment every Sprint.
• The five Nexus events are Cross-Team Refinement, Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, and Nexus Sprint Retrospective.
• Its three artifacts are the Product Backlog, the Nexus Sprint Backlog, and the Integrated Increment, each with its own commitment.
• Its main job is to find and reduce cross-team dependencies before they turn into integration failures.
• It is lighter than SAFe, close in spirit to LeSS, and more structured than the Spotify Model.

Introduction

One Scrum Team building one product is easy to picture. Ten people, one backlog, one Sprint Goal. Then the product grows. A second team joins, then a fourth, then a seventh.

Soon the Sprint Review shows five features that don't work together. The payments team is waiting on the API team. Nobody can say for sure whether the product is releasable.

This is the problem the Nexus framework was built to solve. Instead of wrapping Scrum in new layers of roles and planning cycles, Nexus adds the smallest structure needed to keep several Scrum Teams delivering one integrated product.

In this guide, you'll learn what Nexus is, where it came from, and how its roles, events, and artifacts work. We'll also cover dependency management, adoption steps, a practical Nexus framework example, and a fair comparison with SAFe, LeSS, and the Spotify Model.

What Is the Nexus Framework?

Definition and Purpose

A Nexus is a group of roughly three to nine Scrum Teams working together on a single product. The Nexus framework is the set of rules that connects them. The word "nexus" means a link or connection, and that is exactly the point.

The goal is easy to state and hard to achieve. Every Sprint, the Nexus should produce one Integrated Increment that meets a shared Definition of Done. Not five separate pieces of work. Not "done except for integration." One working product.

To get there, the Nexus Scrum framework focuses on three things:

• Making cross-team dependencies visible early
• Integrating work continuously, not at the end
• Giving one group clear accountability for the integrated result

Origins With Ken Schwaber and Scrum.org

Ken Schwaber, co-creator of Scrum, introduced Nexus with Scrum.org in August 2015. It came out of Scrum.org's work with organizations that had grown from one Scrum Team to many and kept hitting the same wall: integration problems found too late.

The current Nexus Guide (2021) aligns Nexus with the 2020 Scrum Guide.” You can also link the Nexus Guide Change History for the 2018 and 2021 updates. It adds the Product Goal and a commitment for each artifact, removes prescriptive language, and drops software-specific wording so the framework works in other fields too.

Scrum.org also offers the Scaled Professional Scrum (SPS) course and certification for people who want formal training in Nexus.

How Nexus Extends Scrum

Nexus does not replace Scrum. Every team in a Nexus follows the Scrum Guide, a Scrum Master, and Developers. Each team still runs its own Sprint Planning, Daily Scrum, and Sprint Retrospective. Nexus sits on top and adds:

That's the full list.If your teams already know the Scrum events well, the step up to Nexus is small.That's why many practitioners describe Nexus framework scaling Scrum as "Scrum with an integration focus" rather than a new method.

When to Use Nexus

Nexus fits a specific situation: several Scrum Teams, one product, and real dependencies between them. That’s the core challenge of scaling Scrum.

Three to Nine Teams on One Product Backlog

The Nexus Guide describes a Nexus as roughly three to nine Scrum Teams. It's guidance, not a hard rule, but the reasoning matters.

Two teams can usually coordinate through joint refinement and a shared review without a formal framework. Beyond nine, one Product Owner and one integration team start to strain, and communication paths multiply. For larger efforts, Scrum.org describes Nexus+, which links several Nexuses working on the same product.

The other requirement is a single Product Backlog. If your teams own separate products with separate backlogs, you don't have a Nexus. You have independent teams that need occasional coordination, which is a different problem.

Delivering a Single Integrated Increment

Nexus makes sense when every team's work has to combine into one product. Picture a banking app where one team builds onboarding, another builds payments, and a third handles notifications. Customers don't care who built what. They need a payment that triggers the right alert on a verified account.

Nexus is a good fit when:

• Teams share code, data, or user journeys
• Integration problems keep surfacing late in the Sprint or after release
• One Product Owner needs a clear view of overall progress

It's a poor fit when teams are fully independent, or when you need portfolio-level funding and governance across many products.

Nexus Roles

Nexus framework roles are deliberately few. There is one new accountability, the Nexus Integration Team. The familiar Scrum accountabilities continue inside each team.

The Nexus Integration Team

The Nexus Integration Team (NIT) is accountable for making sure the Nexus delivers a done Integrated Increment at least once every Sprint. The Scrum Teams do the work. The NIT makes sure that work comes together.

The Nexus Integration Team includes:

• The Product Owner, who owns the single Product Backlog
• A Scrum Master, accountable for making sure the Nexus framework is understood and enacted
• NIT members with the skills needed to solve integration problems, usually drawn from the Scrum Teams

NIT members often also belong to Scrum Teams. When they work on the NIT, that work comes first. Membership can change as needs shift. A Nexus struggling with building pipelines might add a platform engineer this quarter and a data specialist the next.

Responsibilities of the Nexus Integration Team

The NIT is not a release team that takes integration away from developers. Its job is to raise transparency and remove friction. In practice, it:

• Keeps cross-team dependencies visible and helps teams resolve them
• Spots integration issues early and makes sure someone owns them
• Coaches teams on practices that make integration easier, like shared standards, automated testing, and continuous integration
• Makes sure there is a Definition of Done the Integrated Increment can meet
• Facilitates Nexus events where needed

A useful check: if the NIT is doing most of the integration work itself, something is off. The aim is for Scrum Teams to integrate their own work every day.

How Scrum Team Roles Fit In

One Product Owner can't attend every team's refinement, so Developers take on more refinement work. In a Nexus, that's normal and healthy.

Nexus Events

Nexus framework events wrap around the standard Scrum events. The Sprint is still the container. Each team still holds its own Sprint Planning, Daily Scrum, and Sprint Retrospective. Nexus adds coordination points so the teams act as one.

Cross-Team Refinement

Cross-Team Refinement extends normal backlog refinement across teams, as often as the Nexus needs it. Representatives break down Product Backlog items, work out which team is likely to deliver each one, and surface dependencies.

The point is to reduce dependencies before Sprint Planning, not discover them mid-Sprint. A Sprint with tightly linked work needs more refinement than one with independent items.

Nexus Sprint Planning

Nexus Sprint Planning coordinates all teams for the Sprint. Representatives review and adjust the order of the refined work, and the Product Owner discusses the Nexus Sprint Goal.

Each team then holds its own Sprint Planning, sets a Sprint Goal that supports the Nexus Sprint Goal, and builds its Sprint Backlog. Teams should keep talking during this step, since planning often reveals new dependencies. The result is a Nexus Sprint Goal, a Sprint Goal per team, and a Nexus Sprint Backlog.

Nexus Daily Scrum

At the Nexus Daily Scrum, representatives inspect the state of the Integrated Increment. They look for integration issues and newly discovered cross-team dependencies.

Each team carries that information into its own Daily Scrum. Many Nexuses hold the Nexus Daily Scrum first, so teams can plan their day around integration risks. It isn't a status round. The real question is: what threatens our integrated product today?

Nexus Sprint Review

The Nexus Sprint Review replaces the individual Sprint Reviews of each team. Stakeholders see the Integrated Increment, the whole product working together, instead of a string of separate demos.

The Nexus and stakeholders review progress toward the Product Goal and decide what to do next. The Product Backlog may change based on what they learn.

Nexus Sprint Retrospective

The Nexus Sprint Retrospective is where the Nexus improves how it works as a whole. It looks at issues that cross team lines, such as integration bottlenecks, missed dependencies, or a Definition of Done that keeps slipping. Each team also runs its own retrospective, and insights should flow both ways.

Nexus Artifacts

Nexus framework artifacts follow the 2020 Scrum Guide model. Each artifact has a commitment that gives the Nexus a clear target.

The Single Product Backlog

The whole Nexus works from one Product Backlog, owned by one Product Owner. It holds the Product Goal, the long-term objective every team works toward.

At scale, refinement matters even more. Items need to be clear and small enough that teams can pull them with few dependencies. Some Nexuses tag items with the team most likely to take them, or flag known dependencies, to speed up planning.

The Nexus Sprint Backlog

The Nexus Sprint Backlog combines the Nexus Sprint Goal with the Product Backlog items from every team's Sprint Backlog. Its job is to make dependencies and the flow of work visible during the Sprint.

It's updated at least daily, often at the Nexus Daily Scrum. Many Nexuses use a shared board that shows each team's items with lines drawn between dependent ones. The more lines you see, the more refinement you need.

The Integrated Increment

The Integrated Increment is the sum of all integrated work the Nexus has completed toward the Product Goal. It must be usable and meet the Definition of Done. A feature that works alone but breaks when combined with others isn't done.

The NIT is accountable for a Definition of Done the Integrated Increment can meet. Teams follow it and may add stricter criteria of their own, but they can't loosen it.

How Nexus Manages Dependencies

Dependencies are the main reason scaled Scrum breaks down, and the main thing Nexus is built to handle. They usually come in three forms:

• Requirement dependencies: one feature needs another to exist first
• Knowledge dependencies: a team needs expertise that sits in another team
• Technical dependencies: shared code, services, data, or environments

Making Cross-Team Dependencies Visible

You can't manage what you can't see. Nexus builds visibility into its routine:

1. Cross-Team Refinement maps dependencies before work is pulled.
2. Nexus Sprint Planning sequences dependent work instead of starting it all at once.
3. The Nexus Sprint Backlog shows dependencies on a shared board all Sprint.
4. The Nexus Daily Scrum flags new dependencies the day they appear.

Nexus framework example: A retailer runs a Nexus of five teams on its e-commerce platform. During Cross-Team Refinement, the checkout team learns that its new "pay later" option depends on a credit-check service the platform team hasn't built yet. Rather than both teams starting in the same Sprint and hoping it lines up, the Nexus reorders the backlog. The platform team builds the service first, and checkout picks up the feature the following Sprint. A late surprise becomes a planned sequence.

Reducing Integration Risk Every Sprint

Visibility helps only if you act on it. Nexus pushes teams to lower integration risk all the time:

• Reduce dependencies, don't just track them. Re-split work, move items between teams, or reshape teams to cut handoffs.
• Integrate often. Continuous integration and automated tests catch conflicts in hours, not weeks.
• Agree on shared standards. Common coding, testing, and architecture practices make work easier to combine.
• Avoid "integration Sprints." Saving integration for later lets risk pile up quietly. In Nexus, unfinished integration means the Sprint's work isn't done.

How to Adopt Nexus Step by Step

There's no fixed rollout script, but most successful adoptions follow a similar path:

1. Confirm each team already works well with Scrum.
2. Form the Nexus and the Nexus Integration Team.
3. Merge backlogs into one Product Backlog under one Product Owner.
4. Agree on a shared Definition of Done.
5. Set up the Nexus Sprint Backlog and a dependency board.
6. Run the first Nexus Sprint, then inspect and adapt in the Nexus Sprint Retrospective.

Forming the Nexus and the Integration Team

Start by deciding which teams belong. The rule of thumb is simple: teams that build the same product from the same backlog. Then look at how teams are set up. Cross-functional feature teams that can deliver an end-to-end slice create far fewer dependencies than component teams, such as a separate "database team" and "UI team."

Next, choose the NIT. Include the Product Owner and a Scrum Master who knows Nexus well. Add people with the skills your Nexus needs most right now, such as build automation, architecture, or testing. Keep the group small. Its role is to enable, not to manage.

Many organizations start with three teams and add more once the Nexus events run smoothly. Adding every team at once makes it hard to tell which problems come from Nexus and which come from old habits.

Establishing a Definition of Done Across Teams

A shared Definition of Done holds a Nexus together. Without it, "done" means something different in every team, and the Integrated Increment becomes guesswork.

To build one:

• Bring the NIT and representatives from each team together
• Start with what makes the product releasable: integrated, tested, and deployable
• Write it in plain terms anyone can check
• Let teams add stricter rules, but never weaker ones
• Revisit it in Nexus Sprint Retrospectives and raise the bar as automation improves

If your Definition of Done can't be met every Sprint, say so openly. A modest standard met consistently beats an ambitious one missed quietly.

Nexus vs Other Scaling Frameworks

Nexus is one of several ways to scale agile. Each was built for a different problem, so the right choice depends on your size, structure, and appetite for change.

Nexus vs SAFe

The Nexus framework vs SAFe comparison comes down to scope. Nexus scales Scrum for one product. SAFe scales agile across an enterprise, covering portfolio management, funding, and governance.If you’re new to it, our guide on what the Scaled Agile Framework is explains its levels and configurations.

The main differences:

• Structure: Nexus adds one accountability and five events. SAFe adds multiple roles, levels (team, Agile Release Train, solution, portfolio), and practices.
• Planning: Nexus aligns teams every Sprint. SAFe aligns them at PI Planning, a larger event held every Program Increment.
• Footprint: Nexus suits organizations already running Scrum well. SAFe gives large enterprises a more defined roadmap tied to business strategy.

Neither is better in general. Five teams on one app would find SAFe heavy. A bank with 40 teams across several products may need what SAFe provides. For more on how the two relate, read Scrum Vs SAFe Framework.

Nexus vs LeSS and the Spotify Model

The Nexus framework vs LeSS comparison is the closest one.Both build on Scrum, use one Product Owner and one Product Backlog, and run all teams on a shared Sprint. The difference is emphasis.

Nexus adds a dedicated integration accountability (the NIT) and Nexus-level events. LeSS avoids new roles. It asks organizations to reorganize around feature teams, remove management layers, and treat structural change as part of adoption. Its events include Sprint Planning One and Two and an Overall Retrospective. In short, Nexus is often easier to introduce into an existing setup, while LeSS asks for deeper change.

The Spotify Model is a different kind of thing. It describes how Spotify organized engineering around 2012: squads (small autonomous teams), tribes (groups of squads), chapters (people with the same skill across squads), and guilds (communities of interest). It was never meant as a framework to copy, and Spotify's own practices kept changing. Our article on the Spotify Model covers the structure in detail.

Nexus gives you defined rules for integration and dependencies. The Spotify Model offers ideas about autonomy and culture. Some organizations borrow chapters and guilds while using Nexus to coordinate delivery.

Benefits and Limitations of Nexus

Benefits: Minimal, Scrum-Aligned Scaling

• Short learning curve. Teams that know Scrum already understand most of Nexus.
• Integration comes first. Done means integrated, every Sprint, so problems show up early.
• Clear accountability. The NIT owns the integrated result, so nothing falls between teams.
• Better feedback. One Nexus Sprint Review shows stakeholders the real, combined product.
• Low overhead. No release trains, extra planning layers, or portfolio structures unless you need them.
• Works beyond software. The 2021 guide removed software-only language.

Limitations and When It Is Not Enough

• Limited size. Nexus is built for about nine teams. Larger efforts need Nexus+ or another approach.
• Single-product focus. It doesn't cover portfolio management, budgeting, or strategy across products.
• Depends on Scrum maturity. If teams struggle with Scrum, Nexus will magnify those problems.
• Light on the how. The guide sets rules, not detailed practices. Teams must work out their own dependency techniques.
• Technical prerequisites. Without continuous integration and test automation, an Integrated Increment every Sprint is very hard.
• Product Owner load. One Product Owner across many teams can become a bottleneck without strong team-level refinement.

If you need enterprise-wide alignment, funding models, or heavy governance, a broader framework such as SAFe may serve you better.

The Scrum Master's Role in Nexus

In a Nexus, the Scrum Master works at two levels.

At the team level, nothing changes. Each Scrum Master helps their team use Scrum well, clear impediments, and keep improving.

At the Nexus level, the Scrum Master on the NIT is accountable for making sure the Nexus framework is understood and enacted. In day-to-day terms, that means:

• Coaching teams on Nexus events, artifacts, and the shared Definition of Done
• Facilitating Nexus events when needed and keeping them focused
• Helping the Nexus find and remove cross-team impediments
• Supporting the Product Owner in managing one backlog across many teams
• Encouraging technical practices that make integration routine

Scrum Masters in a Nexus also need to think in systems. A delay in one team often starts somewhere else, so good Scrum Masters look across teams, not just inside their own.

These skills carry over to other scaled setups. If your organization runs SAFe or is moving toward it, SAFe Scrum Master Certification Training shows how the role works inside an Agile Release Train, including PI Planning and cross-team coordination.

Conclusion

The Nexus framework answers a practical question: how can several Scrum Teams build one product without losing what makes Scrum work? Its answer is to add as little as possible. One integration team, five events, and expanded artifacts, all aimed at a single, done Integrated Increment every Sprint.

Nexus works best for three to nine teams sharing one Product Backlog, with solid Scrum habits and good engineering practices. It is lighter than SAFe, close to LeSS in spirit, and more concrete than the Spotify Model.

If dependencies and late integration are slowing your teams down, Nexus is worth a serious look. Start small, make dependencies visible, agree on what "done" means, and improve a little every Sprint.