Nexus, created by Scrum co-creator Ken Schwaber and his team, extends Scrum to guide multiple Scrum teams on how they need to work together to deliver working software in every Sprint. It shows the journey these teams take as they come together, how they share work between teams, and how they manage and minimize dependencies.

The Nexus Guide
Nexus is based on the Scrum Framework and uses an iterative and incremental approach to scaling software and product development. Nexus augments Scrum minimally with one new role and some expanded events and artifacts. The Nexus Framework was created by Ken Schwaber, co-creator of Scrum, and was released by, along with a body of knowledge, the Nexus Guide, in 2015 and updated in 2018. It preserves Scrum.

Nexus additions to Scrum
When you use the Nexus framework, Scrum doesn’t change. Just like adding any practices to Scrum, it is a framework that you build upon, but doesn’t change that foundation itself. The Nexus framework adds a new role, the Nexus Integration Team, a Nexus Daily Scrum, a Nexus Sprint Planning, Nexus Sprint Backlog, and Nexus Sprint Retrospective and Refinement is now formalized as an Event in the framework.

Nexus Integration Team
The Nexus Integration Team is accountable for ensuring that a “Done” Integrated Increment (the combined work completed by a Nexus) is produced at least once every Sprint. The Scrum teams are responsible for delivering “Done” Increments of potentially releasable products, as prescribed in Scrum. All roles for members of the Scrum teams are prescribed in the Scrum Guide.

Nexus Daily Scrum
The Nexus Daily Scrum is an event for appropriate representatives from individual Development Teams to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies or cross-team impacts.

Nexus Sprint Planning
The purpose of Nexus Sprint Planning is to coordinate the activities of all Scrum teams in a Nexus for a single Sprint. The Product Owner provides domain knowledge and guides selection and priority decisions. The Product Backlog should be adequately refined with dependencies identified and removed or minimized prior to Nexus Sprint Planning. During Nexus Sprint Planning, appropriate representatives from each Scrum team validate and make adjustments to the ordering of the work as created during Refinement events. All members of the Scrum teams should participate to minimize communication issues.

Nexus Sprint Backlog
A Nexus Sprint Backlog is the composite of Product Backlog items from the Sprint Backlogs of the individual Scrum teams. It is used to highlight dependencies and the flow of work during the Sprint. It is updated at least daily, often as part of the Nexus Daily Scrum.

Nexus Sprint Retrospective
The Nexus Sprint Retrospective is a formal opportunity for a Nexus to inspect and adapt itself and create a plan for improvements to be enacted during the next Sprint to ensure continuous improvement. The Nexus Sprint Retrospective occurs after the Nexus Sprint Review and prior to the next Nexus Sprint Planning.

Refinement of the Product Backlog at scale serves a dual purpose. It helps the Scrum teams forecast which team will deliver which Product Backlog items, and it identifies dependencies across those teams. This transparency allows the teams to monitor and minimize dependencies.

Refinement of Product Backlog Items by the Nexus continues until the Product Backlog Items are sufficiently independent to be worked on by a single Scrum team without excessive conflict.