Scaling with Nexus: A Practical How-To Guide for Multi-Team Scrum
Nexus is a framework for scaling Scrum. It extends Scrum to coordinate the work of three to nine Scrum teams working together on a single Product Backlog and toward a single Integrated Increment. It was developed by Ken Schwaber and Scrum.org and is described in the Nexus Guide.
Nexus does not replace Scrum -- it adds a thin layer of structure on top of Scrum to manage the cross-team dependencies and integration challenges that arise when multiple teams work on the same product. Understanding what Nexus adds -- and what it does not -- is the starting point for using it effectively.
The Core Nexus Additions to Scrum
The Nexus Integration Team (NIT). The NIT is a cross-functional team whose primary responsibility is to ensure that the work of all Scrum teams is integrated into a working product at the end of each Sprint. The NIT includes the Product Owner (who is the same Product Owner for all teams in the Nexus), a Nexus Scrum Master, and one or more Integration Team members who have the technical skills to resolve integration issues. The NIT does not do development work; it facilitates integration and removes integration impediments.
Nexus Sprint Planning. Before individual Sprint Planning, all teams meet together for Nexus Sprint Planning. The purpose is to identify cross-team dependencies, allocate Product Backlog Items to teams, and ensure that each team understands how their work connects to the work of other teams. Nexus Sprint Planning surfaces dependencies that would otherwise be discovered mid-Sprint, when they are more expensive to resolve.
The Nexus Daily Scrum. Representatives from each team meet daily to identify integration issues and cross-team impediments. The Nexus Daily Scrum is not a status meeting; it is a coordination event focused specifically on integration risks.
The Nexus Integrated Increment. At the end of each Sprint, there is one Integrated Increment -- the combined work of all teams, integrated and tested as a whole. Individual teams may produce team-level increments, but the Nexus standard requires that they be integrated into a single increment that could, in principle, be released.
When to Use Nexus
Nexus is appropriate when a single product genuinely requires more teams than one Scrum team can be. A single Scrum team of five to nine people is usually capable of handling a complex product if the work can be sequenced effectively. Nexus adds coordination overhead; it should only be adopted when the product scale genuinely requires multiple teams.
Nexus is not appropriate as a management structure for multiple independent products. If three teams are each working on separate products, they do not need Nexus -- they need three separate Scrum implementations. Nexus is specifically for multiple teams working on one product.
In 2022, Nexus is particularly relevant for government digital programmes that are scaling up delivery teams to address technology modernisation backlogs. The integration challenges in these environments -- shared data systems, shared APIs, regulatory constraints on deployment -- are exactly the type that Nexus is designed to address.
XNM supports public-sector organisations in designing and implementing scaled agile delivery frameworks. Reach out to XNM's program & project delivery advisory team to discuss Nexus and scaled Scrum implementation for your organisation.