5.6 Scaling Scrum Fundamentals & Nexus Overview

5.6 Scaling Scrum Fundamentals & Nexus Overview

The Cardinal Rule of Scaled Scrum: If a product is large and requires multiple Scrum Teams, all teams work from the SAME Product Backlog and serve the SAME Product Owner. You never create separate Product Backlogs or assign multiple Product Owners to a single product.

As products expand in scale and complexity, organizations often deploy multiple Scrum Teams to accelerate value delivery. However, scaling inherently increases complexity, communication overhead, and cross-team dependencies. To maintain agility, scaled Scrum extends empirical process control while preserving core Scrum rules. Nexus is the official scaled Scrum framework developed by Ken Schwaber and Scrum.org to govern multi-team delivery.

---

Core Scaling Principles

Before exploring specific frameworks like Nexus, PSM I candidates must master the fundamental scaling principles governing multi-team Scrum setups.

1. Single Product, Single Backlog, Single Product Owner

No matter how many teams (whether 2, 5, or 10) work on a single product:

• One Product Owner: Preserves single accountability for product strategy, value optimization, and backlog ordering.
• One Product Backlog: Maintains a single source of truth for work items, requirement updates, and priority.
• One Product Goal: Keeps all participating teams aligned toward a unified long-term target.

                          [ ONE Product Owner ]
                                    |
                          [ ONE Product Backlog ]
                                    |
                          [ ONE Product Goal ]
                                    |
         +--------------------------+--------------------------+
         |                          |                          |
         v                          v                          v
  [ Scrum Team A ]           [ Scrum Team B ]           [ Scrum Team C ]
         |                          |                          |
         +--------------------------+--------------------------+
                                    |
                                    v
                     [ ONE Integrated Increment ]

Why Multiple POs or Backlogs Fail at Scale

Creating separate Product Backlogs or assigning multiple Product Owners to a single product leads to strategic fragmentation, conflicting priorities, siloed component delivery, and massive integration bottlenecks.

---

Overview of the Nexus Framework

Nexus is an operational framework designed for 3 to 9 Scrum Teams working together on a single Product Backlog to deliver a single integrated Increment.

Why 3 to 9 Teams?

• Fewer than 3 Teams: Can usually coordinate cross-team dependencies using standard Scrum communication without formal scaling framework overhead.
• More than 9 Teams: Creates exponential communication complexity (N(N-1)/2 connections), requiring structural domain refactoring or a network of Nexuses.

---

The Nexus Integration Team (NIT)

Nexus introduces one specific scaled role: the Nexus Integration Team (NIT). The NIT exists to ensure that a usable, integrated Increment is produced at least every Sprint by the combined efforts of all participating teams.

+-----------------------------------------------------------------------+
|                    NEXUS INTEGRATION TEAM (NIT)                       |
|  - Accountable for ensuring a Done Integrated Increment every Sprint  |
+-----------------------------------------------------------------------+
                                   |
         +-------------------------+-------------------------+
         |                         |                         |
         v                         v                         v
 [ Product Owner ]         [ Scrum Master ]          [ NIT Members ]
(Single PO for Product)   (Coaches Scaled Scrum)   (Experienced Engineers/
                                                    Architects from Teams)

Composition of the Nexus Integration Team

1. The Product Owner: The single PO holding overall product accountability.
2. A Scrum Master: Accountable for coaching scaled Scrum practices and removing cross-team integration impediments.
3. Nexus Integration Team Members: Experienced engineers and architects who are typically also members of the individual Scrum Teams within the Nexus.

NIT Accountabilities: Coaching vs. Executing Integration

The NIT is accountable for integration, but they do not execute all integration work themselves. Instead, they provide tooling, build automation, continuous integration pipelines, and architectural standards so that the individual Scrum Teams perform integration continuously.

---

Scaled Nexus Events

Nexus scales standard Scrum events to coordinate cross-team dependencies and maintain strategic alignment across the entire Nexus.

---

Minimizing vs. Managing Dependencies

The greatest threat to scaled Scrum performance is cross-team dependencies. Traditional project management attempts to track and manage complex dependencies using elaborate Gantt charts and project managers. Scaled Scrum focuses on minimizing and eliminating cross-team dependencies through feature team design, modular architecture, and continuous integration.

Feature Teams vs. Component Teams

• Component Teams (Anti-pattern at Scale): Teams organized around technical layers (e.g., Database Team, UI Team, Backend Team). Delivering a single end-to-end user feature requires sequential handoffs between 4 teams, creating massive bottlenecks and waiting waste.
• Feature Teams (Recommended): Cross-functional teams capable of delivering a complete end-to-end user slice independently, drastically reducing cross-team friction and dependency handoffs.

---

Scaling Definition of Done & Integrated Increments

In scaled Scrum, work is not complete until it is fully integrated across all participating teams.

• Shared Baseline DoD: All Scrum Teams in a Nexus must adhere to a single integrated Definition of Done.
• Individual Extensions: Individual teams may apply stricter quality criteria for their specific work, but they can never lower or override the shared baseline Definition of Done.
• Integrated Increments: If work from Team A is complete but cannot be integrated with work from Team B, the work is NOT "Done" and cannot be included in the Integrated Increment or released.