What is a Scrum of Scrums? How it works

Introduction

As Scrum teams multiply across a product or program, coordination becomes harder. Dependencies span teams, blockers surface later, and decisions in one area can quickly affect work elsewhere.

A Scrum of Scrums gives teams a structured way to manage that cross-team coordination. Representatives from multiple Scrum teams meet to surface dependencies, resolve shared issues, and keep related work aligned. This guide explains what a Scrum of Scrums is, how a Scrum of Scrums meeting works, who participates, and how teams can use it effectively as part of Agile scaling.

What is a Scrum of Scrums?

A Scrum of Scrums (SoS) is a cross-team coordination practice used when multiple Scrum teams are working on related parts of the same product, program, or delivery effort. It gives those teams a regular forum to surface dependencies, share information that affects others, and resolve impediments that extend beyond a single team.

Each participating Scrum team sends a representative who can speak to the work, risks, and dependencies that matter across teams. This keeps the Scrum of Scrums meeting focused and manageable while allowing individual teams to continue running their own Scrum events.

Scrum of Scrums is commonly used in Agile scaling, especially when several Scrum teams need stronger cross-team coordination. It is a scaling practice rather than one of the events prescribed in the official Scrum framework.

A brief history of Scrum of Scrums

The practice emerged in the 1990s as Scrum began being applied across larger product-development efforts involving multiple teams. Early Scrum practitioners, including Jeff Sutherland and Ken Schwaber, used the approach to help teams coordinate work that crossed team boundaries.

The idea has remained simple: preserve the autonomy of individual Scrum teams while creating a lightweight coordination layer for shared dependencies, integration concerns, and delivery risks.

Scrum vs. Scrum of Scrums

Scrum and Scrum of Scrums operate at different levels of coordination.

In practice, Scrum helps an individual team organize and deliver its work, while a Scrum of Scrums adds the coordination layer required when several teams affect one another's progress.

Why do teams use a Scrum of Scrums?

Team-level Scrum works well when most planning, decisions, and delivery concerns stay within one team. As several Scrum teams begin contributing to the same product or initiative, their work becomes more interconnected. A backend change can delay a frontend release, one team's infrastructure decision can affect another team's implementation, and a shared milestone can depend on several teams moving in sequence.

That creates coordination problems that individual team ceremonies may not surface early enough. Common examples include:

1. Cross-team dependencies: One team cannot complete its work until another team delivers an API, service, component, or decision.
2. Shared blockers: A technical, operational, or product issue affects several teams at once.
3. Integration risks: Separately developed work may create problems when components, services, or releases come together.
4. Conflicting or overlapping work: Teams may make competing changes or solve the same problem without visibility into each other's plans.
5. Limited visibility: Teams know their own priorities but have little context on work happening elsewhere that may affect them.
6. Changes with downstream impact: A scope, architecture, timeline, or priority change in one team can alter another team's plan.
7. Shared releases and milestones: Coordinated delivery requires several teams to align sequencing, readiness, and dependencies.

A Scrum of Scrums meeting gives teams a recurring place to discuss these cross-functional teams' concerns before they turn into larger delivery problems.

What is the purpose of a Scrum of Scrums?

The purpose of a Scrum of Scrums is to create a practical coordination layer across multiple teams. It helps teams keep related work synchronized while preserving the autonomy of each individual Scrum team.

In practice, the approach helps teams:

1. Synchronize related work: Keep sequencing and handoffs aligned across teams.
2. Surface dependencies early: Identify work that relies on another team's output before it becomes a blocker.
3. Resolve cross-team impediments: Bring the right people together around issues that cannot be solved within one team.
4. Improve communication: Give representatives a reliable way to share information that affects other teams.
5. Coordinate shared delivery: Align work around common releases, milestones, or product outcomes.
6. Maintain visibility: Create a clearer picture of how interconnected work is progressing across teams.

This is why Scrum of Scrums Agile practices are commonly used in larger delivery environments where cross-team coordination becomes a regular part of execution.

How does a Scrum of Scrums work?

A Scrum of Scrums works by creating a regular coordination loop between teams that have shared dependencies or delivery risks. Each team continues managing its own backlog, Sprint work, and Scrum events, while the Scrum of Scrums focuses on issues that cross team boundaries.

The basic flow looks like this:

1. Individual teams manage their own work. Each Scrum team continues planning and delivering within its existing process.
2. Each team chooses a representative. The representative should understand the team's current dependencies, risks, and upcoming work well enough to speak on its behalf.
3. Representatives meet at an agreed cadence. The frequency depends on how quickly cross-team work changes and how tightly the teams are connected.
4. Teams discuss work that affects others. Representatives share changes, upcoming work, dependencies, and decisions that may influence another team's plan.
5. Cross-team risks and impediments are surfaced. The group identifies issues that require coordination beyond a single team.
6. Actions and owners are agreed on. Some issues can be resolved during the meeting, while others move into focused follow-up discussions with the relevant people.
7. Information flows back to each team. Representatives return with decisions, updates, and actions that affect their team's work.

The meeting stays useful when the discussion remains centered on cross-team coordination. A detailed recap of everything each team completed adds little value unless that information affects another team's work.

Scrum of Scrums example

Consider three engineering teams working toward the same release:

• The frontend team needs a new authentication API before it can complete a sign-in flow.
• The backend team is building that API, but it depends on a database change owned by the platform team.
• The platform team has discovered that the database migration will take longer than expected.

Without shared visibility, the frontend team may continue planning around an API delivery date that is already at risk.

During the Scrum of Scrums meeting, the platform representative surfaces the delay. The backend team can adjust its API timeline, and the frontend team can reorder work before becoming blocked. The teams can also assign follow-up actions around the migration and update the shared release plan.

This is the core value of the approach: dependencies become visible while teams still have room to respond.

Who participates in a Scrum of Scrums?

There is no fixed attendee structure for a Scrum of Scrums meeting. The right participants are the people who understand the work, dependencies, risks, and decisions that matter across teams.

In most cases, each Scrum team sends one representative. The goal is to keep the group small enough for focused discussion while ensuring every participating team has someone who can speak to cross-team concerns.

Team representatives

A representative might be a:

• Scrum Master, especially when coordination centers on impediments or team process.
• Developer or engineer, when the discussion involves technical dependencies or implementation details.
• Technical lead, when architecture, sequencing, or integration decisions need attention.
• Product Owner, when priorities, scope, or product dependencies are involved.
• Other team member, when someone else has the clearest context on the work being coordinated.

The same person does not have to represent a team every time. Representatives can rotate based on the topics, dependencies, or decisions expected in the meeting. This helps keep the discussion grounded in the work at hand.

Scrum of Scrums facilitator

One person usually facilitates the session to keep the conversation focused and productive. The facilitator helps surface dependencies, keeps the group on the agreed agenda, and makes sure actions and follow-ups have clear owners.

Some organizations informally use the term Scrum of Scrums Master, but this is not a formal role defined by Scrum. Facilitation can be handled by a Scrum Master, delivery lead, engineering lead, or another person suited to the coordination work.

Other participants

Additional people may join when a specific issue requires their expertise or authority. That could include someone from:

• Architecture
• QA
• Platform or DevOps
• Product management
• Program or delivery leadership

Their involvement should be tied to a concrete dependency, risk, or decision. Keeping attendance purposeful helps preserve the value of the meeting as a cross-team coordination forum.

How to run a Scrum of Scrums meeting

An effective Scrum of Scrums meeting needs a clear purpose, the right representatives, a cadence that matches the work, and disciplined follow-through. The meeting should help teams coordinate dependencies and shared risks without becoming another layer of reporting.

A practical setup usually comes down to three things: how often the group meets, how long the discussion runs, and how well representatives prepare.

1. Decide the meeting frequency

There is no universal schedule for a Scrum of Scrums. Some teams meet daily when dependencies change quickly, while others meet several times per week or once a week when coordination needs are more predictable.

The cadence should reflect how tightly the teams depend on one another. A group working toward a shared release with frequent integration points may need more regular coordination than teams whose dependencies change slowly.

The frequency can also change over time. Teams may meet more often during a critical release period, then reduce the cadence once the dependency load decreases.

2. Set an appropriate meeting length

Timeboxing helps keep the discussion focused on issues that require cross-team attention. The right length depends on the number of teams involved, the complexity of their dependencies, and how often the meeting takes place.

Representatives should use the main session to surface issues, clarify impacts, and agree on next steps. Detailed troubleshooting can move into smaller follow-up discussions with the people directly involved. This keeps the broader group focused while still giving complex problems enough space to be resolved properly.

3. Prepare before the meeting

Preparation makes a Scrum of Scrums far more useful. Representatives should arrive with enough context to explain how their team's work could affect others and what support they may need.

Before the meeting, each representative should know:

• What the team has completed that affects others: This could include a finished dependency, API change, scope update, or decision another team is waiting on.
• What the team plans to work on next: Upcoming work may introduce a new dependency or change another team's sequencing.
• Existing dependencies: Representatives should know which teams, systems, services, or decisions their work currently depends on.
• Current blockers: Cross-team impediments should be raised with enough context for the group to understand their impact.
• Relevant risks: Changes in delivery dates, architecture, capacity, or scope may create downstream effects.
• Decisions or support needed: Representatives should be clear about where another team or stakeholder needs to act.

Strong preparation keeps the meeting centered on decisions and coordination rather than spending the first half reconstructing what is happening across teams.

What should a Scrum of Scrums agenda include?

A useful Scrum of Scrums agenda keeps the conversation centered on work that affects more than one team. A common way to structure the meeting is around a small set of questions that help representatives surface dependencies, risks, and upcoming changes.

The discussion can follow questions such as:

1. What has our team completed since the last meeting that other teams should know about?
   Focus on completed work, decisions, or changes that have a direct impact on another team.
2. What will our team work on next that could affect another team?
   This helps teams anticipate upcoming dependencies, sequencing needs, or integration points before they become urgent.
3. What dependencies or blockers are affecting our team?
   Representatives should raise issues that require input, action, or coordination from outside their own team.
4. Are we likely to create a dependency or blocker for another team?
   This question shifts attention toward downstream impact. A team may be progressing well internally while creating a constraint elsewhere through a delayed handoff, interface change, scope decision, or shared-resource conflict.

That final question is especially important because it encourages teams to think beyond their own blockers and consider how their work affects the wider delivery system.

What should come out of the meeting?

A Scrum of Scrums meeting should end with clear outcomes that teams can act on. Typical outputs include:

• Newly identified dependencies: Cross-team relationships that need to be tracked or managed.
• Assigned action owners: Clear responsibility for resolving blockers or completing follow-up work.
• Cross-team decisions: Agreed changes to sequencing, scope, integration, or delivery plans.
• Escalations: Issues that require input or authority beyond the participating teams.
• Follow-up discussions: Smaller working sessions for problems that need deeper technical or product discussion.
• Updated dependency information: Changes to dates, ownership, status, or impact that other teams need to see.
• Blocker resolution actions: Specific next steps for removing impediments.
• Information to share back with teams: Decisions, risks, or changes that representatives need to communicate after the meeting.

The meeting creates value when these outputs feed directly back into team plans and ongoing cross-team coordination.

How to set up a Scrum of Scrums

Setting up a Scrum of Scrums is mostly about deciding who needs to coordinate, what they need to discuss, and how that coordination will continue between meetings. Keep the structure simple at first, then adjust it as the teams learn what works.

Step 1: Identify the teams that need coordination

Start with the teams that regularly affect one another's work.

They may share:

• A product or release
• Technical dependencies
• APIs or infrastructure
• A milestone
• A delivery sequence
• A common customer outcome

There is little value in bringing every Scrum team into the same meeting if their work rarely overlaps. A smaller group with real dependencies will usually have more focused discussions.

For example, if a frontend team depends on an API from the backend team, and the backend team depends on infrastructure changes from the platform team, those three teams have a clear reason to coordinate.

Step 2: Choose representatives

Each team should send someone who understands the work that may affect other teams.

The representative should be able to explain:

• What the team is working on
• Which dependencies exist
• What is currently blocked
• What risks may affect others
• What decisions or support the team needs

The representative does not need to be the same person every time. If the meeting is focused on a technical dependency, an engineer or technical lead may be the best choice. If the discussion involves priorities or scope, a Product Owner may be more useful.

Choose the person who has the clearest context for the issue being coordinated.

Step 3: Define the meeting scope

Agree early on what belongs in the Scrum of Scrums.

The discussion should usually cover:

• Cross-team dependencies: Work one team needs from another.
• Shared blockers: Issues that affect more than one team.
• Integration risks: Problems that could appear when different parts of the work come together.
• Work affecting another team: Changes in scope, architecture, timelines, or implementation that others need to know about.
• Shared milestones: Delivery dates or outcomes that require several teams to stay aligned.

A simple test can help: Does another team need to know about this or take action because of it?

If the answer is yes, it probably belongs in the Scrum of Scrums.

Step 4: Set the cadence and timebox

Choose a meeting rhythm based on how quickly cross-team dependencies change.

Teams with frequent handoffs or a shared release approaching may need to meet several times a week. Teams with fewer dependencies may only need a weekly session.

Keep the meeting timeboxed so representatives focus on the issues that matter across teams. Detailed troubleshooting can continue afterward with the smaller group directly involved.

The cadence can change as the work changes. A release period may require more frequent coordination, while a quieter phase may need less.

Step 5: Create a shared view of dependencies and actions

The work discussed in the meeting should remain visible afterward.

Teams should have a shared place to track:

• Dependencies
• Blockers
• Owners
• Decisions
• Follow-up actions
• Due dates
• Milestones
• Changes that affect other teams

This gives everyone a common reference point between meetings and reduces the need to reconstruct context every time the group meets.

It also makes follow-through easier. If one team is waiting on another, both sides can see who owns the next action and whether the dependency is moving forward.

Step 6: Review and adapt the format

Once the Scrum of Scrums has been running for a few cycles, review whether it is actually helping teams coordinate.

Look at questions such as:

• Are the right teams participating?
• Are representatives able to make useful decisions?
• Are dependencies being surfaced early enough?
• Are blockers receiving clear owners?
• Is the cadence appropriate for the work?
• Are the same issues appearing repeatedly without progress?
• Are teams getting useful information back after the meeting?

Adjust the attendee list, cadence, agenda, or meeting format when needed.

A Scrum of Scrums should evolve with the work. The structure that works for three tightly connected teams during a release may need to change as dependencies decrease, new teams join, or delivery priorities shift.

Benefits of a Scrum of Scrums

When a Scrum of Scrums is working well, the benefits show up in how quickly teams understand dependencies, resolve issues, and coordinate delivery.

1. Earlier visibility into dependencies: Teams can see where work relies on another team before that dependency turns into a delay. This gives them more time to adjust sequencing, ownership, or timelines.
2. Faster blocker resolution: Cross-team impediments reach the people who can act on them sooner. Clear ownership and follow-up also reduce the chance of the same blocker resurfacing meeting after meeting.
3. Stronger coordination around shared delivery: Teams working toward the same release, milestone, or product outcome gain a clearer view of how their work fits together and where timing needs to stay aligned.
4. Better cross-team communication: Representatives have a regular forum to share changes, risks, and decisions that affect other teams, which reduces gaps in information across the wider delivery group.
5. Greater alignment around shared goals: Teams retain ownership of their own work while staying aware of the broader outcome they are contributing to. This helps individual decisions remain connected to shared priorities.

Common Scrum of Scrums challenges and mistakes

A Scrum of Scrums can lose value quickly when the meeting becomes too broad, too crowded, or disconnected from follow-through. Most problems come from losing focus on cross-team coordination.

1. Turning the meeting into a status update

Representatives should share work that affects other teams, rather than recapping everything their team has done.

Once the meeting becomes a general progress report, useful signals such as dependencies, risks, and shared blockers get buried. Keep updates tied to a simple question: Does another team need this information to plan, decide, or act?

2. Sending the wrong representative

A representative needs enough context to explain dependencies, answer questions, and help move issues forward.

If attendees regularly have to take every question back to their team, the meeting slows down, and decisions are delayed. Choose representatives based on the work being coordinated, and rotate them when a different person has better context.

3. Bringing too many people into the meeting

As attendance grows, discussion becomes harder to manage, and participants spend more time listening to issues that do not affect them. Keep the core group limited to relevant team representatives. Bring in specialists or decision-makers when a specific dependency requires their input.

4. Trying to solve every problem during the meeting

Some blockers need deeper technical or product discussion than the main Scrum of Scrums can support. Use the meeting to identify the issue, understand its impact, and decide who should resolve it. The people directly involved can then continue the discussion separately without holding up the wider group.

5. Failing to assign owners

A blocker without an owner is likely to appear again at the next meeting. Every action that comes out of the Scrum of Scrums should have someone responsible for moving it forward. For larger dependencies, teams may also need a target date or a clear next checkpoint.

6. Poor communication back to individual teams

Representatives sit between the Scrum of Scrums and their own teams, so information needs to move in both directions.

Decisions, timeline changes, new risks, and dependency updates should reach the people whose work is affected. Without that feedback loop, the representative becomes an information bottleneck and teams continue working with outdated context.

Scrum of Scrums best practices

A useful Scrum of Scrums depends less on ceremony and more on disciplined coordination. These four practices have the biggest impact on keeping the meeting focused and actionable.

1. Keep the discussion focused on cross-team concerns: Use the meeting for dependencies, shared blockers, integration risks, and decisions that affect multiple teams. Team-level updates can stay within each team's existing Scrum events.
2. Choose representatives based on the work being coordinated: Send people who understand the current dependencies and can speak meaningfully about them. Representatives can change when the nature of the work changes.
3. Make dependencies and next actions visible: Track important dependencies, blockers, owners, and follow-up actions in a shared place. This gives teams a common view between meetings and makes it easier to see whether issues are actually moving forward.
4. Assign clear owners and follow through: Every blocker or action should leave the meeting with someone responsible for the next step. Decisions and updates should also flow back to the individual teams so that coordination continues after the meeting ends.

When should teams use a Scrum of Scrums?

A Scrum of Scrums is most useful when several teams are connected closely enough that one team's work can affect another team's progress, sequencing, or delivery.

Teams should consider using it when:

1. Multiple teams contribute to the same product or outcome: Shared delivery creates a need for regular coordination across team boundaries.
2. Dependencies are frequent or significant: Teams regularly rely on one another for components, decisions, services, or handoffs.
3. Cross-team blockers appear often: Issues repeatedly require action from people outside the affected team.
4. Teams share systems or resources: APIs, infrastructure, environments, platforms, or specialist capacity can create coordination points.
5. Releases require coordinated integration: Several teams need to align timelines, readiness, and integration work around the same milestone.
6. Teams lack visibility into one another's work: A Scrum of Scrums can help surface changes and risks that would otherwise remain inside individual teams.

When might a Scrum of Scrums be unnecessary?

The practice may add little value when teams work largely independently, cross-team dependencies are rare, or existing coordination methods already handle shared issues effectively.

It is also worth reconsidering the meeting if it repeatedly ends without decisions, actions, or useful dependency updates. In that case, the teams may need a different coordination mechanism or a narrower meeting scope.

How does Scrum of Scrums fit into scaled Agile?

Scrum of Scrums is one way to support Agile scaling when multiple teams need to coordinate related work. It provides a lightweight cross-team layer for discussing dependencies, blockers, integration risks, and shared delivery concerns.

Broader scaling approaches handle this coordination in different ways:

• Scrum@Scale uses Scrum of Scrums as part of its coordination structure across multiple teams.
• SAFe uses its own roles, events, and coordination mechanisms across Agile Release Trains and related groups.
• LeSS emphasizes coordination across feature teams while keeping the overall framework deliberately lightweight.
• Disciplined Agile provides a broader decision framework that teams can adapt based on their context and delivery needs.

The terminology and structure vary, but the underlying challenge is similar: as more Agile teams contribute to the same outcome, they need a reliable way to coordinate work across team boundaries.

Managing cross-team dependencies beyond the Scrum of Scrums meeting

A Scrum of Scrums creates a regular coordination point, but dependencies, blockers, and decisions continue to change between meetings. Teams need a shared view of that work so they can act on new information without waiting for the next session.

That means keeping key coordination details visible, including:

• Dependencies between teams
• Blocked work
• Upcoming work that may affect others
• Shared milestones and release dates
• Current work status
• Action owners and follow-up items
• Decisions and the context behind them

A shared system also makes it easier to see whether a dependency is progressing, who owns the next step, and where a delay may affect another team's plan.

Where Plane fits

Plane can support this shared visibility by giving teams one place to manage related projects, Work items, dependencies, Cycles, milestones, and views across ongoing delivery. Teams can keep cross-team work visible between Scrum of Scrums meetings and return to the meeting with a clearer picture of what has changed, what is blocked, and what needs coordination next.

Closing thoughts

A Scrum of Scrums works best when teams use it as a focused coordination layer for work that crosses team boundaries. Its value comes from making dependencies visible early, clarifying ownership, and helping teams respond before shared risks turn into delivery delays.

The meeting itself is only one part of the practice. Clear follow-through, visible actions, and shared context between meetings are what keep cross-team coordination effective as products, teams, and delivery plans evolve.

Frequently asked questions

Q1. What does a Scrum of Scrums do?

A Scrum of Scrums helps multiple Scrum teams coordinate work that affects one another. It gives team representatives a regular place to surface cross-team dependencies, blockers, risks, and decisions so teams can keep shared delivery work aligned.

Q2. Who joins the Scrum of Scrums?

Each participating Scrum team typically sends one representative who understands the team's current work and cross-team dependencies. This may be a Scrum Master, developer, technical lead, Product Owner, or another team member with the right context.

Q3. What are the three pillars of Scrum?

The three pillars of Scrum are transparency, inspection, and adaptation. Transparency makes important work and progress visible, inspection helps teams evaluate outcomes and emerging issues, and adaptation allows them to adjust their plans or approach based on what they learn.

Q4. Who should attend a Scrum of Scrums?

People who can speak clearly about cross-team work should attend a Scrum of Scrums. The attendee may vary depending on the topic, so teams can rotate representatives when a developer, technical lead, Product Owner, or another specialist has more relevant context.

Q5. Is Scrum like Six Sigma?

Scrum and Six Sigma address different types of improvement. Scrum is an Agile framework for managing complex product development through iterative planning, delivery, and feedback. Six Sigma is a process-improvement methodology focused on reducing defects and variation through data-driven analysis. Organizations can use elements of both when their goals overlap.