Scaling Scrum — From One Team to Many

When Scaling Becomes Necessary

A single Scrum team of 3-9 people works beautifully. Communication is direct, integration is continuous, and the team owns the full delivery cycle. But when the product grows beyond what one team can handle, organisations add teams — and immediately face problems that single-team Scrum never prepared them for.

Signs you need to scale:

• The backlog consistently has more high-priority work than one team can deliver
• The team is growing beyond 9 people and communication is breaking down
• Different parts of the product require specialised skills that don't fit in one team
• Delivery speed has plateaued despite adding people

The Core Challenge: Integration

The primary challenge of scaling is not coordination — it's integration. Multiple teams must produce a single, working, integrated increment every sprint. This means:

• All teams work from one Product Backlog (not separate backlogs per team)
• Code from all teams integrates continuously (not at the end of the sprint)
• The Definition of Done applies to the combined increment (not per-team increments)
• Dependencies between teams are identified and resolved within the sprint

Scaling Frameworks Compared

Nexus (3-9 teams, one product)

Created by Ken Schwaber (co-creator of Scrum), Nexus is the lightest scaling framework. It adds minimal overhead to Scrum:

• Nexus Integration Team: A small group (Scrum Masters + key developers from each team) responsible for ensuring integration works
• Nexus Sprint Planning: Teams plan together, identify cross-team dependencies, and agree on integration points
• Nexus Daily Scrum: Representatives from each team sync on integration issues (15 minutes)
• Nexus Sprint Review: One combined review of the integrated increment

Best for: organisations that want to stay close to Scrum with minimal additional process.

LeSS (2-8 teams, one product)

Large-Scale Scrum (LeSS) takes a different philosophy: descale the organisation rather than add process. Key principles:

• One Product Owner, one Product Backlog, one Definition of Done
• Teams are cross-functional and feature-focused (not component teams)
• Sprint Planning has two parts: all teams together (Part 1) then individual teams (Part 2)
• One Sprint Review with all teams and stakeholders
• Overall Retrospective in addition to team retrospectives

Best for: organisations willing to restructure teams around features rather than components.

SAFe (50+ people, multiple products)

The Scaled Agile Framework is the most comprehensive (and heaviest) option. It adds:

• Agile Release Trains (ARTs) of 50-125 people
• Programme Increments (PIs) of 8-12 weeks
• PI Planning events (2 days, all teams together)
• Release Train Engineers (RTEs) to coordinate the ART
• Multiple layers: Team, Programme, Large Solution, Portfolio

Best for: large enterprises (50-5000+ people) that need formal governance and alignment across many teams.

Practical Steps for Scaling

Step 1: Restructure teams around value streams

Component teams (frontend team, backend team, database team) create handoffs and dependencies. Feature teams that can deliver end-to-end value independently reduce coordination overhead dramatically.

Before: Frontend team → Backend team → QA team → DevOps team (4 handoffs per feature) After: Feature Team A owns checkout end-to-end, Feature Team B owns search end-to-end (zero handoffs within a feature)

Step 2: Establish a single Product Backlog

Multiple backlogs per team lead to local optimisation and conflicting priorities. One backlog, one Product Owner (or a small PO team with one chief PO), one priority order.

For large products, use "requirement areas" — slices of the backlog that map to feature teams. Each team pulls from their area, but the overall priority is set centrally.

Step 3: Solve integration continuously

The biggest risk in multi-team Scrum is integration failure at the end of the sprint. Prevent this by:

• Continuous integration: all teams merge to the main branch multiple times per day
• Shared Definition of Done that includes "integrates with other teams' work"
• Automated integration tests that run on every merge
• A dedicated integration environment where the combined increment is always visible

Step 4: Manage dependencies explicitly

Dependencies between teams are the primary source of delivery risk at scale. Make them visible:

• Dependency board: A shared board showing all cross-team dependencies with owners, dates, and RAG status
• Scrum of Scrums: Daily 15-minute sync between team representatives to surface blockers and dependencies
• Sprint Planning alignment: Teams plan together (or at least share plans) so dependencies are identified before the sprint starts

Step 5: Align on cadence

All teams should work on the same sprint cadence (same start/end dates). This enables:

• Synchronised Sprint Reviews (stakeholders see the integrated increment)
• Cross-team Sprint Planning (dependencies identified together)
• Shared retrospectives for systemic issues
• Predictable delivery rhythm for stakeholders

What Changes for the Scrum Master

At scale, the Scrum Master role expands:

• Team coaching remains core — each team still needs facilitation, impediment removal, and process improvement
• Cross-team coordination becomes critical — facilitating Scrum of Scrums, dependency resolution, and integration
• Organisational coaching grows — helping leadership understand why feature teams outperform component teams, why shared backlogs matter, why integration must be continuous
• Community of Practice — building a Scrum Master community across teams to share patterns, solve common problems, and maintain consistency

Common Scaling Anti-Patterns

Adding process instead of removing impediments: The answer to scaling problems is rarely "more meetings." Look for structural solutions (team topology, architecture, automation) before adding coordination ceremonies.

Component teams at scale: Scaling with component teams multiplies dependencies exponentially. Two component teams have 1 dependency. Four have 6. Eight have 28. Feature teams are the structural solution.

Multiple Product Owners with no alignment: Each team has its own PO making independent decisions. Result: conflicting priorities, duplicated work, and an incoherent product. One chief PO must own the overall priority.

Big-bang integration: Teams work independently for the whole sprint and attempt to integrate on the last day. Result: integration failures, emergency fixes, and incomplete increments. Integrate continuously from day one.

Measuring Scaling Health

• Integration frequency: How often does the combined increment build successfully? (Target: multiple times per day)
• Cross-team dependency resolution time: How long do blocked items wait? (Target: resolved within the sprint)
• Combined increment quality: Escaped defects from integration issues (Target: decreasing trend)
• Team autonomy: What percentage of sprint work can a team complete without depending on another team? (Target: >80%)

---

Download the [Dependency Matrix template](/templates) to track cross-team dependencies as you scale.