Imagine three Scrum teams, each running their own sprints, all working on the same product. Team A builds the checkout flow. Team B owns the inventory service. Team C handles notifications. These teams are not islands — their work collides at integration points, and without coordination, they'll step on each other constantly.
Scrum of Scrums (SoS) is the simplest scaling solution: a meta-team made up of one representative from each Scrum team, meeting regularly to coordinate.
Learning Objectives
- Describe the structure and purpose of a Scrum of Scrums ceremony
- Explain what makes an effective Scrum of Scrums ambassador
- Identify the types of dependencies that SoS is designed to resolve
- Recognise the limitations of SoS and when a different approach is needed
What is Scrum of Scrums?
Scrum of Scrums was informally described by Jeff Sutherland in the mid-1990s — he reportedly borrowed the idea from a story about Whitesmiths Ltd. using the pattern to coordinate work across teams.
The structure is deliberately minimal:
- Each Scrum team sends one ambassador (also called a delegate or representative)
- Ambassadors meet regularly — daily or a few times per week — for a short synchronisation session
- The session focuses on inter-team dependencies, not team-internal updates
The four SoS questions (an evolution of the Daily Scrum questions):
- What has my team completed since we last met that other teams should know about?
- What will my team complete before we meet again that affects other teams?
- What impediments is my team facing that another team could help resolve?
- Is my team about to cause something that will create problems for another team?
Note the last question — it's the most important one and the most often skipped. It requires teams to self-report upcoming disruptions, which requires a culture of psychological safety and transparency.
The Ambassador Role
Not everyone should be an ambassador. The ideal candidate:
- Has a broad view of the team's current work (not siloed in one task)
- Can make decisions or quickly escalate to the right person
- Communicates clearly and concisely
- Has the trust of their team to represent them accurately
In many teams, the Scrum Master serves as ambassador by default. This works when the Scrum Master has deep enough technical context to spot dependencies. It fails when the Scrum Master is a purely process-focused role with limited domain knowledge.
QA engineers make excellent SoS ambassadors — they typically have the broadest view of what's working and what's broken across the system, because their job requires understanding how pieces integrate.
Dependency Management in SoS
The primary output of a SoS session is a shared understanding of cross-team dependencies and a plan to resolve them.
Types of dependencies:
| Type | Example | Resolution approach |
|---|---|---|
| Delivery dependency | Team B needs Team A's API before they can build feature X | Shared sprint goal; early API design |
| Resource dependency | Both teams need the same test environment on Day 5 | Schedule coordination; environment pool |
| Knowledge dependency | Only Team C knows how the notification service works | Documentation; joint session; pair work |
| Timing dependency | Team A's release will break Team B's integration | Release coordination; feature flags |
The Dependency Board is a common SoS artifact: a simple board (physical or digital) that lists known cross-team dependencies with their status (identified, in progress, resolved, at risk).
Limitations of Scrum of Scrums
SoS works well for 3-5 teams. It starts to break down with more teams:
- More ambassadors means longer, less focused sessions
- Dependencies become harder to track as the number of teams grows
- The SoS itself can become a bottleneck, requiring its own coordination layer
Beyond ~5 teams, organisations typically need either a Scrum of Scrum of Scrums (nested SoS) or a different framework like LeSS or SAFe.
Pro Tip: The most common failure of Scrum of Scrums is when it becomes a status meeting — each ambassador reports what their team is doing, and nobody asks the hard questions about dependencies and upcoming conflicts. Guard against this by explicitly asking "Is anyone about to cause a problem for another team?" at every session.
Summary
- Scrum of Scrums is a meta-ceremony for cross-team coordination with one ambassador per team
- The four SoS questions focus on inter-team impact, not team-internal status
- QA engineers often make the best ambassadors because of their system-wide view
- Dependency tracking is the primary deliverable of SoS
- SoS scales to about 5 teams; beyond that, additional coordination layers are needed