A Summary of Nexus — a Scaled Scrum Framework

This post is a straight up summary of Nexus. I’ve written it as a reference for myself and (hopefully) a quick primer for you. I’ll save a critical analysis for another post.

Definition

Nexus is a framework which rests on top of 3 to 9 Scrum teams. It provides structure for how multiple Scrum teams work together on a single Product Backlog to build an Integrated Increment every Sprint.

Nexus = Scrum + dependency removal logic

It was created by the team at Scrum.org, headed by a Ken Schwaber, a co-creator of Scrum.

The Aim

To optimize productivity by removing dependencies which are common to multiple teams working toward a common goal.

What’s New?

• Roles — A Nexus Integration Team which coordinates, coaches and supervises the application of Nexus and Scrum.
• Artifacts — Nexus Sprint Backlog and a single product backlog managed by the Nexus Product Owner. Also, the Integrated Increment, a common Definition of “Done”, Nexus Sprint Goal is introduced.
• Events — Nexus Sprint Review, Nexus Sprint Retrospective, Refinement, Nexus Daily Scrum.

Process Flow

1. Refine the Product Backlog

Aims to forecast what teams do what work, identify dependencies in that work and “thinly slice” that work. It’s a two step process:

1. Decompose product backlog items to understand which teams might deliver them and in what sequence
2. Focus on minimizing/removing dependencies.

2. Nexus Sprint Planning

Coordinate activities of all Scrum teams for a single Sprint, by:

1. Adjusting work order with appropriate Scrum team members (post-Refinement events)
2. Define the Nexus Sprint Goal
3. Then do Sprint Planning for each Scrum team.

3. Nexus Sprint Backlog

Visualize the combined Scrum team Sprint Backlogs along with their dependencies.

4. Development Work

Same ol’.

5. Nexus Daily Scrum

Scrum Development Team representatives attend this event to identify a) integration issues, b) cross-team dependencies at the backdrop of a visualized Nexus Sprint backlog. Dependencies that are identified are taken back to individual Scrum teams.

Three questions are asked in this event:

1. Was the previous day’s work successfully integrated? If not, why not?
2. What new dependencies have been identified?
3. What information needs to be shared across teams in the Nexus?

6. Nexus Sprint Review

Replaces individual Scrum Team Sprint Reviews and functions as a combined version of these.

7. Nexus Sprint Retrospective

There are three parts:

1. Appropriate members meet and make shared issues transparent in a Nexus Sprint Retrospective.
2. Scrum Teams hold their own Sprint Retrospectives
3. Appropriate members re-meet, form actions for shared issues, visualize these and track them.

All retrospectives should address the following questions:

1. Was any work left undone? Did the Nexus generate technical debt?
2. Were all artifacts, particularly code, frequently (as often as every day) successfully integrated?
3. Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?

5 Common Activities of a Nexus Integration Team

1. Coaching
2. Consulting
3. Highlighting dependencies and cross-team issues
4. Perform work from the Product Backlog
5. Work in other Scrum teams (with Nexus Integration Team work taking precedence)

How does this differ from Scrum?

It’s the formalization of dependency removal when multiple Scrum teams work together, with a fine-tuning of the questions asked in Scrum events.