Scrum of Scrums
A coordination mechanism where representatives from multiple Scrum teams meet regularly to share progress, surface cross-team dependencies, and resolve impediments.
What it is
Scrum of Scrums (SoS) extends the Daily Scrum to multiple teams. Each team sends one or more representatives to a regular coordination meeting. The format mirrors the Daily Scrum but focuses on inter-team concerns rather than individual progress.
The three questions are adapted for cross-team communication:
- What has my team done since we last met that affects other teams?
- What will my team do before we meet again that affects other teams?
- What is blocking my team that requires help from other teams?
Scrum of Scrums is a coordination practice, not a full scaling framework. It can be used alongside Scrum, Kanban, or any other agile approach. Many organisations adopt it as their first scaling step before committing to Nexus, LeSS, or SAFe.
When to use it
| Use SoS when… | Consider alternatives when… |
|---|---|
| You have 3 or more Scrum teams with interdependent deliverables | Teams are fully independent with no cross-team dependencies |
| You need lightweight coordination without a formal scaling framework | You need integrated increments with strict accountability (consider Nexus) |
| Teams already have healthy Scrum practices | Teams are not yet proficient at single-team Scrum |
| You want to experiment with scaling before committing to a framework | You have more than 9 teams and need structural scaling (consider LeSS or SAFe) |
Key concepts
Representatives
Each team sends one or more representatives. These are typically Scrum Masters, technical leads, or rotating team members. The key is that they have enough context to speak for their team and enough authority to commit to actions.
The Three Questions
Adapted from the Daily Scrum, the questions focus on impact across team boundaries. The goal is not to report status but to identify and resolve cross-team issues.
Decision Authority
Representatives must have authority to make decisions or commit to actions on behalf of their team. Sending someone who must "check and get back to you" defeats the purpose.
Nested SoS
At larger scale, Scrum of Scrums can be nested. Multiple SoS groups each send a representative to a higher-level coordination meeting. This pattern scales to large programmes while keeping individual meetings small.
Common pitfalls
| Pitfall | Why it happens | How to avoid it |
|---|---|---|
| Turning it into a status meeting | Management wants visibility into all teams | Keep focus on inter-team dependencies and blockers; take other reporting elsewhere |
| Sending representatives without authority | Team leads are too busy; juniors are sent instead | Ensure attendees can make commitments and remove impediments |
| Including too many people | Everyone wants to be informed | Keep it small; 2–3 representatives per team maximum |
| Focusing on updates rather than dependencies | Habit from traditional project management | Use the three cross-team questions explicitly |
| Not following through on actions | No one owns the outcomes | Track actions visibly; review them at the next SoS |
NZ context
New Zealand organisations with 3–8 agile teams commonly use Scrum of Scrums as their primary scaling mechanism. The local preference for informality and direct communication makes this lightweight approach particularly effective.
A single Scrum of Scrums held 2–3 times per week is often sufficient for NZ product teams. Daily meetings can feel excessive when teams are small and co-located; the key is matching frequency to actual dependency density.
Career level guidance
| Level | What to know | What to demonstrate |
|---|---|---|
| Junior | Understand what SoS is and why teams use it | Can describe the three cross-team questions |
| Intermediate | Know how to represent your team effectively | Can attend SoS, raise relevant dependencies, and report back accurately |
| Senior | Understand how to keep SoS effective and lean | Can facilitate SoS, prevent status-meeting drift, and drive action follow-through |
| Test Lead / QA Lead | Understand quality and testing dependencies across teams | Can raise cross-team quality risks and coordinate integration testing needs |
Industry Reality
- Most organisations run SoS as an informal catch-up rather than a structured ceremony — the three cross-team questions are rarely asked explicitly, but the same topics surface anyway through conversation.
- In practice, the "representative" is often the Scrum Master attending every SoS rather than a rotating team member; decision authority is frequently absent, so outcomes get deferred to follow-up conversations.
- SoS meetings routinely drift into programme status reporting once executives discover they exist — senior practitioners actively resist this by keeping the invite list tight and parking management reporting on a separate cadence.
- Many NZ teams running 3–5 squads skip SoS entirely and rely on a shared Slack channel or a weekly dependency board review instead — effective when teams have low integration risk, problematic when they don't.
- Nested SoS (SoS of SoS) looks clean on paper but is rare outside large banks and government programmes; most organisations dissolve the structure before they get that big, or adopt SAFe's PI planning instead.
Context guide
How the right level of Scrum of Scrums effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| HealthNZ or CoverNZ programme with 4+ squads sharing patient data APIs and an auth layer | Essential | Shared clinical data contracts and privacy obligations under the Health Information Privacy Code mean integration defects carry compliance risk; SoS is the earliest mechanism for surfacing contract drift before it reaches UAT. |
| Revenue NZ or Benefits NZ multi-squad delivery with audit and change management obligations | Essential | Regulatory systems require traceable cross-team decision records; SoS must be supplemented with a dependency register in Jira or Confluence to satisfy audit requirements — verbal-only coordination is not sufficient. |
| Harbour Bank or Pacific Bank digital banking feature programme with 3–6 squads | High | Banking release windows are narrow and shared; a missed cross-team dependency discovered in regression typically forces a release deferral. SoS 2–3 times per week keeps integration risk visible before the window closes. |
| TeleNZ or Pacific Air product squad cluster with low API coupling | Medium | When squads own independent microservices with versioned contracts, dependency density is low enough that a weekly SoS or a dependency board reviewed async may be sufficient; daily frequency creates ceremony overhead without proportional benefit. |
| Single NZ product startup scaling from one team to two | Low | Two small co-located teams typically coordinate informally through daily conversation; introducing a formal SoS at this scale adds process overhead that outweighs the coordination benefit — a shared dependency board is usually enough. |
| TransitNZ or LandNZ programme with 8+ squads spanning multiple release trains | Low | At this scale SoS alone cannot hold programme-level alignment; the coordination surface is too large for 15-minute meetings. Adopt Nexus or SAFe PI planning — SoS may still exist as a sub-layer within each train, but it is not the primary mechanism. |
Trade-offs
What you gain and what you give up when you adopt Scrum of Scrums.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Zero framework overhead — can be adopted by any team running Scrum, Kanban, or a hybrid without restructuring roles or ceremonies | No built-in accountability mechanism — blockers raised in the meeting can go unresolved if no one owns follow-through and there is no visible dependency board to expose stale items | Teams need enforced integrated definition-of-done and a formal integration team — adopt Nexus instead, which mandates a dedicated integration team per sprint |
| Forces early surfacing of cross-team dependencies at the start of each sprint rather than at the integration or UAT gate, where resolution is expensive | Leaves no auditable record of cross-team decisions — a 15-minute verbal meeting is indefensible for regulated environments such as Revenue NZ or Privacy Act 2020 compliance programmes | Your context requires a formal traceability trail — supplement SoS with a structured dependency register in Confluence or Jira, or adopt a framework that mandates written artefacts |
| Scales naturally to a nested pattern (SoS of SoS) without requiring a new framework or role structure — matches the informal coordination style that NZ public-sector and mid-market organisations typically prefer | Susceptible to executive capture — once leadership starts attending, the meeting drifts from dependency resolution to programme status reporting, destroying the psychological safety needed for representatives to raise real blockers | Stakeholder alignment across all teams is needed simultaneously rather than incrementally — SAFe PI Planning is more effective because it brings all teams and business owners into a single structured event with explicit risk identification |
| Keeps inter-team communication rhythmic and predictable — teams know exactly when cross-team blockers will be heard, which reduces the cognitive load of tracking who to contact and when | Representative quality is uneven — effective SoS depends entirely on each representative having context and decision authority; when either is absent, the meeting produces discussion but not resolution | Teams are genuinely independent with no shared APIs or release dependencies — a shared async channel or dependency board review is lower overhead and equally effective when integration risk is low |
Enterprise reality
How Scrum of Scrums changes at 200–300-developer scale in NZ
- At this scale, dependency tracking moves out of the SoS meeting itself and into automated tooling — Jira dependency visualisers, Backstage service catalogues, or custom dashboards fed by CI pipelines. The meeting becomes a triage layer on top of what the tooling already surfaces; anything not pre-populated on the board does not get discussed.
- Governance obligations reshape the format significantly. Revenue NZ's Revenue NZ transformation programme (one of NZ's largest public-sector IT deliveries, spanning dozens of squads over many years) required a written dependency register updated after every SoS and traceable to change advisory board approvals — the Privacy Act 2020 and NZISM controls meant verbal-only coordination was never acceptable for changes touching personal tax data.
- With 10 or more squads, a flat SoS collapses under its own weight — a single meeting cannot hold that many dependency threads. The standard NZ enterprise pattern is to cluster squads into value streams (payments, identity, data, channels) each with its own SoS, then run a SoS-of-SoS at programme level with one delegate per cluster. That delegate needs genuine decision authority, not just observer status, or the escalation chain adds a week to every blocker resolution.
- PCI DSS compliance (relevant at Harbour Bank, Coastal Bank, KiwiFirst Bank, and any squad touching card payment flows) adds a non-negotiable audit trail requirement: every cross-team agreement that could affect a cardholder data environment must be recorded, timestamped, and linked to a change ticket. At this scale, the SoS chair role becomes a formal position with a compliance checklist, not just whoever facilitated last sprint.
◆ What I would do
Professional judgment — when to adopt Scrum of Scrums, when to adapt it, and what to watch for.
The bottom line: Scrum of Scrums is a forcing function, not a reporting mechanism — if your meeting is surfacing the same blockers week after week without resolution, the problem is not the format, it is that the people in the room do not have the authority or the dependency visibility to resolve anything. Fix those two things before you fix the agenda.
Best Practices
- ✓ Timebox SoS strictly to 15 minutes — if a cross-team issue needs deeper discussion, schedule a separate working session rather than dragging everyone through it.
- ✓ Rotate representatives periodically so knowledge of cross-team concerns isn't siloed in one person; Scrum Masters should facilitate, not monopolise the representative role.
- ✓ Maintain a visible dependency board (physical or digital) that SoS updates — attendees come prepared because they've already seen what's blocked.
- ✓ Track actions with named owners and due dates; review them at the start of every SoS before raising new items.
- ✓ Run SoS at a cadence that matches actual dependency density — 2–3 times per week is common for tightly coupled teams; weekly may be enough for loosely coupled ones.
- ✓ Keep attendance to one or two representatives per team; a room with 12 people from four teams is not a Scrum of Scrums, it's a programme meeting.
- ✓ Separate impediment escalation from SoS itself — if something can't be resolved within the meeting, escalate it immediately after rather than carrying it as a standing agenda item.
- ✓ As a QA or test lead, come to SoS with your integration testing dependencies explicit — which teams' outputs you need, when you need them, and what risks a delay creates.
Common Misconceptions
❌ Myth: Scrum of Scrums is just a big Daily Scrum for all the teams.
Reality: SoS is a cross-team coordination meeting, not an aggregate of individual team updates. Individuals do not report their own progress — representatives speak only to what affects other teams. If it sounds like a round-robin of "what everyone did yesterday," the meeting has drifted into status reporting and needs resetting.
❌ Myth: You need a formal scaling framework (SAFe, LeSS, Nexus) before you can coordinate multiple teams.
Reality: Scrum of Scrums is a lightweight coordination pattern that predates all major scaling frameworks. Many organisations — especially smaller NZ product companies — run 4–6 agile teams successfully with just SoS and a shared backlog, never needing the overhead of a full framework.
❌ Myth: The Scrum Master must always be the SoS representative for their team.
Reality: The most effective SoS representative is whoever has the best context on cross-team dependencies right now — often a tech lead or senior developer, not the Scrum Master. Rotating the representative role builds shared awareness across the team and prevents a single point of failure in cross-team communication.
Senior engineer insight
The teams that run Scrum of Scrums well treat it as a dependency resolution meeting, not a progress broadcast — representatives arrive with blockers already named and leave with owners assigned. The single pattern that consistently separates effective SoS from ceremony theatre is the pre-populated dependency board: when everyone can see the board before the meeting starts, the 15 minutes are spent on decisions rather than discoveries. Teams that skip the board almost always drift into round-robin status updates within two sprints.
The most common mistake: sending the Scrum Master as a permanent proxy with no rotation — it turns cross-team awareness into a single-person silo and means the meeting collapses whenever that person is absent or moves on.
From the field
On a six-squad programme modernising a NZ government payments platform, the test coordinator assumed that because all teams used the same Jira board, cross-team test dependencies were visible to everyone — so no SoS was set up for the first three sprints. What actually happened was that two squads discovered in UAT week that they had independently implemented conflicting validation rules for the same transaction type, neither having raised it because neither knew the other was touching it. A twice-weekly SoS with a shared dependency board was introduced immediately, and within one sprint the integration defect rate at UAT dropped significantly. The lesson that transferred beyond that programme: shared tooling creates the possibility of visibility, but a structured forcing function — a meeting with a named owner per dependency — is what creates actual resolution.
Self-Check
Click each question to reveal the answer.
Q: Your organisation is running five squads delivering a new HealthNZ patient portal. Two squads share an API contract and a third squad owns the shared auth layer. How would you structure a Scrum of Scrums for this programme, and what would you prioritise in each meeting?
A: With tightly coupled squads, run SoS three times a week rather than daily to avoid ceremony overload while still catching integration risks early. Each meeting should lead with the shared API contract status and auth layer readiness — these are the highest-dependency items. Representatives from the API-consuming squad and the API-owning squad should come with a named version or interface change logged on a dependency board beforehand, so the SoS surfaces blockers rather than discoveries. The auth squad representative should flag any breaking changes at least one sprint ahead, giving consuming teams time to adapt.
Q: What is the key difference between a Scrum of Scrums and a PI Planning event in SAFe, and when would you choose one over the other?
A: Scrum of Scrums is a lightweight, recurring coordination meeting (typically 15 minutes, two to three times per week) focused on near-term cross-team dependencies and blockers. PI Planning is a structured quarterly event where all teams in a SAFe Agile Release Train align on a programme increment's goals, risks, and dependencies simultaneously. Choose SoS when you have three to six teams that need ongoing dependency management without the overhead of a full framework — common in NZ product companies. Choose PI Planning when you have eight or more teams with complex interdependencies, external stakeholders to align, and a need for programme-level predictability over a longer horizon.
Q: A developer on your programme says "we don't need Scrum of Scrums — we just use a shared Slack channel and everyone can see what's happening." What is the risk with this approach and how do you respond?
A: Passive visibility in a Slack channel is not the same as active dependency resolution. A channel surfaces information only when someone posts it, which means blockers and integration conflicts often go unspoken until they become critical. Scrum of Scrums creates a forcing function — a scheduled moment where representatives are accountable to raise cross-team issues, even uncomfortable ones. That said, the developer has a point: if your teams genuinely have low dependency density and mature communication norms, a channel-plus-dependency-board combination may be sufficient. The question to ask is whether cross-team blockers are being resolved in hours or days — if it's days, a structured SoS cadence is likely warranted.
Q: You are the QA lead on a programme delivering an Revenue NZ income tax system upgrade across four squads. When is Scrum of Scrums the wrong coordination mechanism for this context, and what would you recommend instead?
A: SoS becomes the wrong choice when compliance and audit requirements demand formal traceability of cross-team decisions — a 15-minute verbal meeting leaves no defensible record. For a regulated Revenue NZ system, you would supplement SoS with a formal dependency register updated in Jira or Confluence, and a structured integration testing checkpoint at the end of each sprint where all four squads sign off on contract compatibility. If the programme grows beyond six squads or spans multiple release trains, consider adopting Nexus or a scaled SAFe configuration that enforces integrated definition-of-done across teams. SoS is best treated as the daily coordination layer, not the compliance or governance mechanism.
Why teams fail here
- Misaligned authority: Representatives attend but cannot commit — every decision requires a follow-up conversation with someone who wasn't in the room, doubling resolution time and making the SoS feel pointless to the people running it.
- Executive capture: Once leadership discovers the SoS exists, they start attending "just to observe" — within weeks it becomes a programme status meeting and the cross-team dependency conversation moves to a hallway chat instead.
- No dependency board: Without a visible, pre-populated board, each SoS starts from scratch — teams re-surface the same blockers week after week because there's no shared record of what was agreed last time and whether it was resolved.
- QA and test left until the end: Integration testing dependencies — which team's API needs to be stable before the test team can start regression — are routinely omitted from SoS discussions, then land as a crisis in the last sprint when the test coordinator finally raises them.
Key takeaway
Scrum of Scrums done well is a 15-minute decision engine, not a meeting — it exists to convert cross-team blockers into named owners before those blockers become sprint-ending crises.
How this has changed
The field moved. Here is how Scrum of Scrums evolved from its origins to current practice.
Ken Schwaber mentions the Scrum of Scrums concept — when multiple Scrum teams work on the same product, a representative from each meets to coordinate dependencies. The simplest possible scaling mechanism.
Mike Cohn popularises the Scrum of Scrums: each team sends a representative to discuss what was done, what is planned, and what dependencies or blockers exist.
Scrum of Scrums scales to multiple layers at very large organisations. The practice remains valuable but informal compared to SAFe's Programme Increment planning.
SAFe, LeSS, and Nexus provide more structured alternatives for very large teams. For 2-5 teams, Scrum of Scrums remains the simplest coordination mechanism.
Digital collaboration tools have partially replaced synchronous Scrum of Scrums meetings. At scale, PI planning provides the deeper coordination that Scrum of Scrums cannot — but for small multi-team programmes, it remains effective.