The Scrum of Scrums: A Beginner's Guide

A single Scrum team -- typically five to nine people -- is the basic unit of Scrum. But many products are too large or too complex to be built by a single team within reasonable timelines. Organisations respond by forming multiple Scrum teams working in parallel on the same product. This creates a new problem: how do those teams coordinate with each other? The Scrum of Scrums is one of the oldest and most widely used patterns for solving this problem. Here is what beginners need to know.

What the Scrum of Scrums Is

The Scrum of Scrums (SoS) is a regular coordination meeting for representatives from multiple Scrum teams working on the same product or programme. It is not defined in the Scrum Guide -- it predates the Guide and has been in use since the late 1990s -- but it is widely applied and has a well-established pattern.

In its simplest form, one representative from each Scrum team attends the Scrum of Scrums meeting. The typical cadence is two to three times per week. Each meeting is short -- typically 15 to 30 minutes -- and follows a format similar to the Daily Scrum, but focused on cross-team issues rather than individual team issues. The discussion covers: what did the team complete since the last SoS that other teams need to know about? What are we working on before the next SoS that might affect another team? Are there any impediments that are blocking us that require another team's help to resolve?

Who Attends (and Who Should Not)

The representative from each team is typically an experienced developer -- someone who understands the technical details of the work well enough to identify cross-team dependencies and integration issues. It is not always the Scrum Master. The Scrum Master may attend as an observer or facilitator, but the meeting is most effective when the person who actually knows what the team is building is in the room.

This is one of the most commonly misunderstood aspects of the Scrum of Scrums. Senior managers sometimes attend or chair these meetings as a substitute for their own status updates. This changes the dynamic immediately. Team representatives become cautious about what they say, because the meeting now feels like a performance review rather than a peer-to-peer coordination forum. The SoS works because it is a practitioner-level conversation, not a management briefing.

• Who should attend: One representative per Scrum team -- typically the developer most familiar with the team's current work and its dependencies.

• Who should not attend: Managers, executives, or anyone whose presence will cause team representatives to self-censor rather than raise real impediments.

• Scrum Masters: May attend as neutral facilitators, but the meeting is not a Scrum Master meeting -- it belongs to the teams.

When It Works and When It Does Not Scale

The Scrum of Scrums works well when the number of teams is small (typically two to five), the teams share a common codebase or integration surface, and the representatives genuinely understand each other's work well enough to spot dependencies. In this context, it is a lightweight, low-overhead coordination mechanism that surfaces integration issues early rather than discovering them during Sprint Review.

The pattern begins to break down at larger scale. With eight or ten teams, a 15-minute meeting becomes unmanageable. The list of cross-team issues grows faster than the meeting can address them. Dependencies are too numerous and too complex to track verbally. Organisations with ten or more teams typically need a more structured coordination approach -- frameworks like SAFe (Scaled Agile Framework) or LeSS (Large-Scale Scrum) provide more comprehensive models for this level of scale, though they introduce considerably more overhead.

It also does not work when the teams are not actually interdependent -- when each team is working on a fully independent component with no shared integration points. In that case, the Scrum of Scrums becomes a meeting in search of a purpose. If teams consistently report no impediments or dependencies affecting other teams, reconsider whether the meeting is adding value.

XNM supports public-sector organisations implementing Scrum and scaled agile delivery models. Reach out to XNM's program & project delivery advisory team to discuss Scrum coaching and multi-team coordination for your organisation.