Scrum-of-Scrums (SoS) is one of the oldest and simplest techniques for coordinating multiple Scrum teams working toward a shared goal. First documented by Jeff Sutherland and Ken Schwaber in the late 1990s and subsequently developed by Sutherland as a core component of Scrum@Scale, the Scrum-of-Scrums provides a lightweight coordination mechanism that extends the stand-up model to the inter-team level — surfacing cross-team dependencies, integration challenges, and shared blockers in a regular, structured forum without creating the heavyweight programme management overhead that traditional scaling frameworks often impose. For project managers overseeing multi-team Agile programmes, understanding how to design, facilitate, and evolve a Scrum-of-Scrums is a practical delivery management capability.
What Problem Scrum-of-Scrums Solves
When multiple Scrum teams work on a shared product or programme, coordination challenges inevitably emerge that individual team stand-ups cannot address. Team A is building an API that Team B depends on to complete a critical feature — but Team A’s work is blocked by a third-party dependency that neither team has visibility of. Teams C and D are both planning to modify the same data model in the same sprint — a conflict that will produce integration failures in the final week. Team E has discovered a shared platform limitation that will affect Teams B, D, and F — but without a cross-team communication forum, this discovery remains invisible to the affected teams until it appears as a blocker in their individual stand-ups.
These coordination failures are not failures of individual team Scrum — they are failures of inter-team visibility and alignment that no single team’s ceremonies can address. The Scrum-of-Scrums creates the coordination layer that makes these issues visible at the programme level where they can be resolved proactively rather than discovered reactively as sprint-blocking surprises.
The Scrum-of-Scrums Structure
The Scrum-of-Scrums meets regularly — typically two to three times per week for active programme delivery phases, with daily cadence appropriate during integration-intensive periods — and follows a format analogous to the team-level daily stand-up but oriented toward cross-team coordination rather than individual daily planning.
Each team sends one ambassador to the Scrum-of-Scrums — typically the team’s Scrum Master, though some teams rotate the ambassador role among senior developers to build broader cross-team awareness. The ambassador answers four questions on behalf of their team: What did our team complete since the last SoS that other teams should know about? What will our team work on before the next SoS? Are there any impediments blocking our team that are outside our ability to resolve? Are we about to put anything in another team’s way?
The fourth question — “are we about to create problems for another team?” — is the most distinctive and most valuable addition to the stand-up format at the inter-team level. It forces ambassadors to think forward about downstream impacts of their team’s current work, surfacing potential integration conflicts and dependency creation before they become blocking problems.
The Scrum-of-Scrums Master
In Scrum@Scale, the Scrum-of-Scrums has a designated facilitator called the Scrum-of-Scrums Master (or Chief Scrum Master) — an experienced Scrum practitioner who facilitates the SoS meeting, owns the programme-level impediment log, and works to resolve cross-team blockers that individual teams cannot resolve independently. The SoS Master plays a similar role to the individual team’s Scrum Master but at the inter-team coordination level: removing cross-team impediments, ensuring the SoS remains focused on coordination rather than becoming a status meeting, and protecting the SoS format from the feature-discussion and problem-solving scope creep that frequently derails it.
“Scrum-of-Scrums scales the stand-up’s core value — shared visibility and fast impediment surfacing — to the programme level. It is coordination through transparency, not coordination through control.” — Jeff Sutherland, Scrum@Scale Guide
Common Scrum-of-Scrums Anti-Patterns
The Scrum-of-Scrums is simple enough to implement badly. The most common anti-patterns that undermine its effectiveness:
- Status report meeting: The SoS becomes a programme status meeting where ambassadors report sprint progress to a programme manager rather than coordinating with each other. This fundamentally misuses the format — the SoS is a peer coordination forum, not a management reporting channel.
- Problem-solving in the meeting: When cross-team impediments are identified, the SoS attempts to resolve them in the meeting itself — ballooning the timebox from 15 minutes to 60+ minutes and making the meeting expensive and demoralising. Identified problems should be assigned to owners for offline resolution, never discussed to resolution in the SoS itself.
- Wrong ambassador: Ambassadors who are not empowered to make commitments on behalf of their team, or who do not have sufficient technical context to identify genuine cross-team risks, produce a coordination forum with participation but no value.
- Infrequent cadence: A weekly SoS for teams working in two-week sprints means that cross-team impediments surfaced on Monday may not be visible to the affected team until the following Monday — a five-day visibility gap in a ten-day sprint is too long to maintain flow.
When to Introduce Scrum-of-Scrums
The Scrum-of-Scrums is appropriate for any context where two or more Scrum teams share dependencies, integration points, or a common codebase. The threshold is not the number of teams but the frequency of cross-team dependencies — two tightly integrated teams need SoS coordination more urgently than five teams working on largely independent modules. Before introducing SoS, ensure each participating team has a mature enough Scrum practice that their ambassador can genuinely represent their team’s work and risks — a team that does not yet run effective stand-ups will not be able to populate the SoS with useful, actionable information.
Scrum-of-Scrums vs Other Scaling Mechanisms
| Mechanism | Coordination Type | Meeting Overhead | Best For |
|---|---|---|---|
| Scrum-of-Scrums | Impediment & dependency visibility | Very low (15 min, 2–3x/week) | 2–8 teams, continuous coordination |
| SAFe PI Planning | Quarterly aligned planning | High (2 days, every 10 weeks) | Large ART (50–125 people) |
| LeSS Sprint Review | Cross-team product review | Medium (per sprint) | 2–8 teams on one product |
| Communities of Practice | Knowledge and standards sharing | Low (periodic, voluntary) | Cross-team standards alignment |
Key Takeaways
- Scrum-of-Scrums provides lightweight inter-team coordination — surfacing cross-team dependencies, integration issues, and shared blockers that individual team stand-ups cannot address.
- The four ambassador questions — completed, planned, blocked, about to block others — extend stand-up thinking to the programme level; the fourth question is the most distinctive value-add.
- The SoS Master owns the programme impediment log and resolves cross-team blockers — the SoS meeting itself surfaces issues, it does not solve them.
- The most damaging anti-patterns are status meeting drift, problem-solving in the meeting, wrong ambassador, and insufficient meeting cadence — each has a specific corrective design intervention.
- Cadence should match integration intensity — daily SoS during integration sprints, 2–3 times per week during normal delivery, reducing to weekly only when cross-team dependencies are low.
- SoS is most effective when individual team Scrum practice is mature — teams that do not run effective stand-ups cannot generate the cross-team visibility information the SoS requires.
