Nexus Framework: Scaling Scrum Without Breaking It

Why it exists

Scrum is designed for a single team. When multiple teams work on the same product, they create dependencies and integration problems that can derail sprints. Nexus was created by Scrum.org to solve this scaling problem by providing a minimal, prescriptive framework that builds upon, rather than replaces, Scrum.

The mental model

Think of Nexus as an exoskeleton for multiple Scrum teams. The individual teams are the skeleton, still operating with their own events and autonomy. Nexus adds a lightweight outer layer—the Nexus Integration Team and shared events—to coordinate their movements, manage shared pressure points (dependencies), and enable them to act as a single, larger organism to deliver one integrated product increment.

How it works

Nexus introduces a few key elements on top of existing Scrum teams. First, a Nexus Integration Team is formed, consisting of the Product Owner, a Scrum Master, and members from the development teams. This team is accountable for ensuring a "Done" Integrated Increment is produced. Second, it uses a Nexus Sprint Backlog, which makes the combined work of all teams and their dependencies transparent. Third, it adds new events like the Nexus Daily Scrum and Nexus Sprint Planning to handle cross-team coordination, integration issues, and overall process improvement.

When to use it

Use Nexus when you have between three and nine Scrum teams all working from a single Product Backlog on a single product. It is ideal when the primary challenge is managing dependencies and integration complexity between these teams to produce one cohesive product increment per sprint. It provides just enough structure to solve this coordination problem without excessive overhead.

When not to use it

Nexus is not for situations where teams work on separate products with separate backlogs. It is also likely overkill for just two teams, who can often coordinate informally. For more than nine teams, you may need a more robust framework like LeSS Huge or SAFe, or to scale Nexus itself (Nexus+), as the communication overhead becomes too large for a single Nexus.

One canonical example

A mobile banking app has separate Scrum teams for user accounts, fund transfers, and bill payments. A Nexus is formed. The Nexus Integration Team identifies a dependency: the fund transfer team needs an API from the user accounts team. This is flagged in the Nexus Sprint Backlog. During the Nexus Daily Scrum, representatives from both teams coordinate the API delivery and integration testing, preventing a last-minute failure where the transfer feature cannot be merged.