Nexus

Origins

Nexus was developed by Ken Schwaber (one of Scrum's co-creators) and released through Scrum.org in 2015.¹ The framework targets a specific scaling problem: how to coordinate a small number of Scrum teams (3 to 9) building a single product, with integration risk taken seriously rather than left implicit.

Where Scrum@Scale aims to scale recursively to any size, and LeSS commits to a single Product Owner across teams, Nexus focuses on the specific challenges of small multi-team programs and elevates one issue most other frameworks underplay: integration.

The Distinctive Element: The Nexus Integration Team

Nexus introduces an explicit Nexus Integration Team — a small group whose accountability is ensuring that the increments from the multiple Scrum teams integrate into a single, working, valuable product increment. The integration team is not a separate team of integrators; it's typically a Product Owner, a Scrum Master, and selected Nexus team members who collectively own this concern.

The framework's logic: with three to nine teams working on one product, integration becomes the highest-risk activity in the program. Treating it as an emergent property — hoping it works out — produces predictable failure. Treating it as a first-class accountability with explicit ownership produces fewer surprises.

The Events

Nexus extends the Scrum events with cross-team coordination versions:

• Nexus Sprint Planning. Begins with a cross-team alignment session that identifies dependencies and integration challenges before each team plans its own sprint.
• Nexus Daily Scrum. A daily standup of representatives from each team to surface and address cross-team issues.
• Nexus Sprint Review. A single review where the integrated increment is shown, not separate per-team demos.
• Nexus Sprint Retrospective. A cross-Nexus retrospective focused on the integration and coordination, complementing per-team retros.

Each event has explicit hooks for integration risk — which teams are touching the same code, what's the integration plan, what conflicts surfaced today.

The Single Product Backlog

Nexus shares LeSS's commitment to a single Product Backlog across all teams. Items are decomposed during refinement to make them suitable for single-team work, but there's one ordered list of priorities.

Where Nexus Earns Its Keep

• Programs of 3–9 teams on a single product. Below 3, Nexus is overkill; above 9, the framework strains.
• Integration-heavy work. When teams routinely touch the same components, the integration emphasis is genuine value.
• Organizations that want Scrum.org-aligned guidance. Nexus is the official Scrum.org scaling framework; aligned certifications, training, and ecosystem.
• Cultures that respond well to explicit accountability. The Nexus Integration Team is a real construct, not advisory.

Where Nexus Struggles

• Programs of more than 9 teams. The framework explicitly acknowledges its scope limit. Larger programs need Nexus+ (Nexus of Nexuses) or a different framework.
• Independent products bundled into one. If the "single product" is actually three loosely-coupled products, the integration emphasis becomes overhead.
• Strongly stream-aligned teams. Teams that don't share code or integration concerns don't benefit from Nexus's integration machinery.
• Cultures attached to elaborate ceremony. Nexus is lighter than SAFe but still adds machinery; some teams find even that excessive.

How Nexus Differs from Scrum@Scale and LeSS

• Versus Scrum@Scale: Nexus is scoped explicitly to 3–9 teams; Scrum@Scale recurses without limit. Nexus emphasizes integration; Scrum@Scale emphasizes recursion.
• Versus LeSS: Both share a single backlog and feature-team focus. Nexus adds explicit integration machinery and a scoped team count; LeSS is structurally simpler but assumes integration emerges from team coordination.
• Versus SAFe: Nexus is dramatically lighter. Where SAFe adds a release train and PI Planning, Nexus adds an integration team and integration-focused events.

Coaching Tips

Verify the integration concern is real.

If teams don't actually touch each other's code, Nexus's integration machinery is unnecessary. Different framework, different problem.

Staff the Integration Team carefully.

It needs technical depth across the system. The wrong people produce process without integration.

Run the Nexus Daily as integration sync.

Not as status. Surface integration issues, not what each team did yesterday. The format matters.

Refine cross-team dependencies early.

Nexus refinement surfaces dependencies. Resolve them or split items before sprint start.

Watch for Nexus drift to status meetings.

The cross-team events can drift into status reporting. Discipline keeps them focused on integration.

Don't exceed the 9-team limit.

Beyond 9 teams, Nexus strains. Either split into multiple Nexuses or rethink the team structure.

Summary

Nexus fills a specific niche in the scaling framework landscape: small multi-team programs where integration is the central coordination challenge. By naming an explicit integration team and weaving integration concerns into each scaled event, the framework takes seriously what others leave implicit. For organizations whose work fits the framework's design — 3–9 teams, single product, real integration concerns — Nexus is often the right choice. For organizations outside those bounds, other frameworks fit better.

Back to Scaling Agile