Scrum of Scrums: Agenda, Attendees and How to Run One That Works

A Scrum of Scrums is a short coordination meeting where one representative from each team surfaces cross team blockers and dependencies. It is not a status meeting. The representative should usually be a technical contributor rather than the Scrum Master, and the agenda covers what affects other teams rather than what each team did.

Key Highlights

• One person attends per team, chosen by that team, and the choice should rotate depending on what issues are likely to arise.
• The representative is usually best drawn from the people building the work rather than the Scrum Master or Product Owner, because integration problems need someone who can discuss them technically.
• Frequency is decided by the teams. Ken Schwaber originally suggested daily for no more than 15 minutes, though many organisations settle on two or three times a week.
• The agenda mirrors the Daily Scrum but reframed to team level, since one person speaks for a whole team and the meeting is not daily.
• A no names rule keeps discussion at team level rather than sliding into individual updates, which is the most common way the meeting degrades.
• Scrum of Scrums is a scaling pattern, not part of the Scrum Guide. Nothing about it is prescribed, so teams should adapt it deliberately.

What a Scrum of Scrums Is For

The Scrum of Scrums exists to solve one problem: when several teams work on the same product, things that fall between them have nowhere to be discussed.

A single team handles this in the Daily Scrum. Add four more teams and the coordination surface expands quickly. Team A is waiting on an interface from Team C, Team B has changed something that breaks Team D's assumptions, and nobody finds out until integration.

The Scrum of Scrums is a regular slot where exactly those issues surface. Its purpose is not visibility for management, and it is not a place for teams to report progress. It is a place for teams to discover what is about to affect them.

That distinction determines everything else about how the meeting should run, and getting it wrong is why so many of these meetings feel like a waste of time.

Worth stating plainly: Scrum of Scrums does not appear in the Scrum Guide. It is a widely used scaling pattern rather than official Scrum, which means nothing about it is fixed. Teams are free to adapt it, and should.

If you are stepping into a Scrum Master role where you will facilitate this, our free CSM practice test is a quick check on your grounding in the framework before formal training.

Who Should Attend

This is where most teams make their first mistake.

Each team sends one representative, and the team chooses who. That much is standard. What surprises people is the recommendation that the representative should usually be a technical contributor rather than the Scrum Master or Product Owner.

The reasoning is practical. The issues that need resolving in this meeting are frequently technical: an interface changing shape, a shared service behaving unexpectedly, a deployment sequence that needs coordinating. Someone building the work can discuss those directly and commit to a resolution. A Scrum Master often has to take the question away and come back.

There is a second effect. When every attendee is a Scrum Master, the meeting drifts toward process and status by default, because that is the language the room shares. When attendees are the people doing the work, it drifts toward solving the actual problem.

The representative should also rotate. If the coming fortnight involves a database migration, send whoever understands that. If it involves a front end integration, send someone else. Fixing the attendee permanently means the meeting is only ever as useful as one person's area of knowledge.

None of this excludes the Scrum Master from attending. Facilitating the meeting is a reasonable role for one of them. The point is that the team's voice in the room should be someone who can engage with the substance.

The Agenda

The agenda borrows from the Daily Scrum and reframes it, because one person is speaking for a whole team and the meeting may not be daily.

The four questions each representative answers:

What has my team completed since we last met that affects other teams? Not everything the team did. Only what other teams need to know about.

What will my team do before we next meet that affects other teams? Again filtered for relevance. Upcoming changes to shared components, interfaces or environments belong here.

What is blocking my team that another team could resolve? The most important question in the meeting, and the reason it exists.

What is my team about to do that might block someone else? The question most often left out, and the one that prevents the most problems. It asks people to anticipate rather than report.

That fourth question is worth protecting. Teams are generally good at raising what is blocking them and poor at flagging what they are about to break for someone else, because the consequence lands elsewhere.

After the round, spend the remaining time on the issues raised. The round itself should be brisk. If it consumes the entire meeting, nothing is being resolved and the session has become reporting.

Frequency and Timebox

Neither is prescribed, and teams should choose deliberately rather than defaulting.

Ken Schwaber's original suggestion was daily, capped at 15 minutes. In practice many organisations find that too frequent, and settle on two or three times a week.

The useful test is how often cross team issues actually arise. Teams with heavy integration and shared components benefit from daily contact. Teams working largely independently with occasional touchpoints find daily meetings mostly empty, and empty meetings train people to stop paying attention.

A reasonable starting point is three times a week, adjusting after a month based on what actually happens. If most sessions have nothing substantive, reduce frequency. If issues routinely wait several days to surface, increase it.

Keep the timebox tight regardless. Fifteen to thirty minutes is normal. The discipline that makes this work is the same discipline that makes any timeboxed event work: hold the boundary and move detailed problem solving to a follow up with only the people involved.

The No Names Rule

A simple technique that changes the meeting more than its simplicity suggests.

The rule is that no individual names are used. Representatives speak about teams rather than people. Not Priya is finishing the payment endpoint, but the payments team expects the endpoint ready by Thursday.

Removing names keeps the discussion at the level the meeting is for. Once individuals enter the conversation, the meeting slides toward who is doing what, which is a team's internal business and not a cross team concern. It also invites a subtle form of performance monitoring that damages trust between teams.

The practical effect is a filter. If a point cannot be expressed at team level, it probably belongs in that team's own Daily Scrum rather than here.

Teams find this awkward for a week or two and then stop noticing. The improvement in focus is usually immediate.

Scrum of Scrums Compared With Other Coordination Mechanisms

It helps to know what this meeting is and is not competing with, because organisations frequently run several overlapping forums without noticing.

The confusion that causes most trouble is between the Scrum of Scrums and the programme status meeting. They look similar, they often have overlapping attendees, and they serve opposite purposes.

A status meeting reports outward to people who need to know how things are going. A Scrum of Scrums is teams talking to each other about what will affect them. The moment the first purpose enters the second meeting, representatives start presenting rather than problem solving, and the coordination stops.

If your organisation genuinely needs both, run them separately with different attendees. Merging them saves half an hour and costs the coordination entirely.

Similarly, a Scrum of Scrums does not replace PI planning or equivalent longer horizon planning. It handles what emerges between planning events. Teams that use it to do planning work find it consumes far more time than the format supports.

Making It Work Remotely

Most Scrum of Scrums sessions now run remotely at least part of the time, and the format needs small adjustments.

Keep a shared visible list of open issues rather than relying on memory or notes taken by one person. Remote participants have no peripheral awareness of what was raised last time, and a document everyone can see does the job that a physical board would.

Use written input for the round where the group is large. Representatives type their four answers before the session, and the meeting starts from that rather than spending ten minutes on verbal reporting. This frequently halves the length and improves the discussion, because everyone has read everything rather than only remembering the last speaker.

Be explicit about who is speaking next. The natural turn taking cues that work in a room do not exist remotely, and without a stated order the round becomes hesitant and slow.

Hold the timebox harder than in person. Remote sessions drift more, and a Scrum of Scrums that regularly overruns is one people begin skipping.

Where teams span wide time zones, consider making the round asynchronous entirely and using the live time only for discussion. Reporting reads perfectly well in writing. Resolving a dependency between two teams generally does not.

Signals It Is Working

Rather than assessing the meeting by attendance or punctuality, look for these.

Blockers are raised before they bite. The clearest signal. If issues consistently surface in the Scrum of Scrums rather than at integration, the meeting is doing its job.

Teams occasionally change their plans because of it. A representative hearing that another team is about to alter a shared component, and adjusting their Sprint accordingly, is exactly the intended outcome.

The fourth question produces answers. When representatives regularly flag what they are about to do that might block others, the meeting has shifted from reporting to anticipation.

Issues close. Track how many raised items resolve before the next session. A rising number of repeats means the follow up discipline has slipped.

People bring things voluntarily. In a healthy session, representatives raise issues outside the formal round because the forum has become the obvious place to do so.

Conversely, the strongest warning sign is silence. A meeting where nobody raises a blocker for several sessions running is almost never a sign that everything is fine. It usually means people have concluded that raising things achieves nothing, and that conclusion is very hard to reverse once it sets. Preventing it is largely a facilitation responsibility, and it is one of the areas CSM Certification Training addresses directly.

Common Failure Modes

Six patterns account for most unproductive Scrum of Scrums meetings.

It becomes a status meeting. Each representative reports what their team did, nobody raises a blocker, and the meeting ends having achieved nothing. This is the default state without active facilitation, and it is usually a symptom of the wrong attendees or a manager in the room.

Discussion drops into technical detail. Two teams start solving an integration problem in depth while six other representatives wait. The fix is to name it, park it, and have those two continue afterwards.

Single team concerns dominate. Someone raises something only affecting their own team. It may be important and it does not belong here.

Management attends. Once someone with authority over budgets or performance is present, representatives stop raising problems honestly. The meeting still happens and stops surfacing anything real.

Nothing gets followed up. A blocker is raised, everyone agrees it needs sorting, and nobody owns it. By the next session it is raised again. This is the same failure that undermines retrospectives, and the remedy is identical: a named owner and a date.

The same person always attends. The meeting becomes limited to one person's understanding, and other team members lose visibility of cross team context entirely.

What Happens After the Meeting

The Scrum of Scrums surfaces issues. It rarely resolves them inside the timebox, and that is fine provided something happens afterwards.

Every issue raised needs a named owner. Not a team, a person. Cross team blockers stall precisely because both sides assume the other is handling it, so the meeting should not end without that being explicit.

Issues also need somewhere to live. A visible list that gets reviewed at the start of each session works well, and reviewing it first is what creates accountability. The pattern is the same as tracking any dependency: an item without an owner and a date is a note rather than a commitment.

Some issues will exceed what the representatives can resolve. Those need escalating rather than reappearing at every session. Where a blocker sits with a function outside all the teams present, someone has to take it there, and that is usually a Scrum Master or Release Train Engineer responsibility.

One practical addition that costs nothing: note which team raised each item and which team owns the resolution. Cross team issues frequently stall because the raising team assumes the owning team is progressing it while the owning team considers it the raiser's problem to chase. Recording both sides removes that ambiguity entirely.

Representatives should also carry information back. A meeting whose output stays with the eight people who attended has coordinated nothing. Two minutes in each team's next Daily Scrum covering what came up is what closes the loop.

When You Need Something More

The Scrum of Scrums works well up to a point and then stops scaling.

The arithmetic is the reason. Two teams have one relationship. Five have ten. Ten have forty five. A single coordination meeting with ten representatives becomes long, and most of what is discussed is irrelevant to most attendees.

Several responses exist once you pass roughly eight or nine teams.

Split into groupings that share genuine dependencies, with a smaller coordination meeting above them. This is sometimes called a Scrum of Scrum of Scrums, which sounds absurd and works reasonably.

Adopt a framework built for the problem.LeSS attacks it by removing dependencies structurally with feature teams and a single backlog. SAFe accepts them and provides coordination machinery through the Agile Release Train and PI planning.

Or reduce the need for coordination. This is the least popular and most effective option. If ten teams need daily coordination, the boundaries between them are probably drawn across the work rather than around it. More meetings treat that symptom, and the common problems in scaling agile are largely this issue appearing in different forms.

Facilitating It Well

The meeting needs someone running it, and the facilitation is what separates useful from ritual.

Open with the outstanding issues from last time rather than the round. This immediately signals that the meeting is about resolution, and it makes unowned items visible.

Keep the round moving. If a representative starts explaining their team's internal work, a short redirect to what other teams need to know is enough.

Notice what is not being said. Teams under pressure often stop raising blockers, because raising them feels like admitting difficulty. A facilitator who knows two teams are integrating next week can ask directly rather than waiting.

Close by confirming owners. Whoever is facilitating should state the actions and who holds them before ending, and that summary should take a minute.

This is coordination facilitation rather than process administration, and it draws on the same skills as running any difficult multi party conversation. The wider Scrum Master skill set covers it, and it is developed practically inCSM Certification Training.

A Sample Agenda

For a session with five teams, timeboxed to 30 minutes.

Two notes on that structure.

The round is deliberately short. Two minutes per team is enough for relevant cross team information and not enough for a status report, which is the intended constraint.

Discussion gets the largest block because that is where the value is. A session that spends twenty five minutes on the round and five on discussion has the proportions backwards, and it is the most common shape in practice.

A Worked Session

Concrete beats abstract, so here is a session that goes well and the same one going badly.

Five teams work on a lending platform. The session is 30 minutes, three times a week, facilitated by one of the Scrum Masters.

The version that works. The facilitator opens with the three issues from Monday. Two are closed, one is not, and the person who owned it explains why in a sentence. That takes four minutes.

The round begins. The payments team mentions they are changing the response format on a shared endpoint on Thursday. The onboarding team representative immediately says they consume that endpoint and had not heard. That exchange takes forty seconds and prevents a broken integration.

The origination team raises a blocker: they need a test environment refresh that only the platform team can perform, and it has been outstanding six days. The platform representative commits to it by Wednesday, and the facilitator notes the owner and the date.

Discussion covers the endpoint change in a little more detail, agreeing that the two teams will meet afterwards to align on timing. Nobody else has to sit through that conversation.

The session closes with three owned actions. Total time, 22 minutes.

The version that fails. The facilitator opens with the round. Each representative describes what their team completed last Sprint, in detail, because that is what reporting feels like. Twenty two minutes gone.

The payments team mentions the endpoint change in passing, buried in a longer update. Nobody catches it. The onboarding team discovers it the following Tuesday when their integration tests fail.

The origination team does not raise the environment blocker, because the last two things they raised went nowhere and it felt like complaining.

The session ends on time with no actions. Everyone agrees it was fine.

The difference is not the agenda. Both sessions used the same four questions. The difference is that the first opened with accountability for last time, filtered the round to what other teams need, and ended by naming owners.

Frequently Asked Questions

1. What is a Scrum of Scrums?

A coordination meeting where one representative from each team surfaces cross team dependencies and blockers. It is a scaling pattern used when multiple teams work on the same product, and it is not part of the Scrum Guide.

2. Who should attend the Scrum of Scrums?

One person per team, chosen by that team, and usually a technical contributor rather than the Scrum Master or Product Owner. The representative should rotate depending on what issues are likely to arise.

3. How often should it be held?

Teams decide. Daily for 15 minutes was the original suggestion, though many organisations use two or three times a week. Base it on how often cross team issues actually arise.

4. What questions are asked?

What has my team done that affects others, what will we do that affects others, what is blocking us that another team could resolve, and what are we about to do that might block someone else.

5. How long should it take?

Fifteen to thirty minutes depending on the number of teams. Detailed problem solving should move to a follow up with only the people involved.

6. Is Scrum of Scrums part of Scrum?

No. It is a widely used scaling pattern rather than an official Scrum event, which means teams can adapt it freely to their situation.

7. Should managers attend?

Generally no. Their presence tends to suppress honest reporting of blockers, which is the entire purpose of the meeting.

8. Can the Scrum of Scrums replace the Daily Scrum?

No. They operate at different levels. The Daily Scrum coordinates work inside one team and belongs to that team's developers. The Scrum of Scrums coordinates between teams. Removing either leaves a gap the other cannot fill.

9. How many teams can one Scrum of Scrums support?

Comfortably up to about eight or nine. Beyond that the session becomes long and most of what is discussed is irrelevant to most attendees, and the usual answer is to split into groupings that share genuine dependencies.

10. What if the meeting has nothing to discuss?

That is a signal to reduce frequency. Consistently empty sessions teach people the meeting does not matter, which damages attendance when something genuinely does need raising.

Closing Thoughts

The Scrum of Scrums is simple to describe and easy to run badly. Most versions fail the same way: the wrong people attend, everyone reports what their team did, no blocker is raised, and the meeting persists because it is in the calendar.

Three changes fix most of them. Send someone who can engage with the substance rather than defaulting to the Scrum Master. Ask what your team is about to do that might block someone else, not just what your team has done. And open each session with what happened to last session's issues, which is the habit that turns a discussion into coordination.

One further note for anyone introducing it. Do not start a Scrum of Scrums because the organisation has multiple teams. Start it because a specific coordination problem keeps occurring. Meetings created to satisfy a structure rather than to solve something observable tend to have nothing to discuss from the first week, and that pattern is very difficult to recover from.

It is also worth remembering what the meeting is compensating for. Heavy coordination need is usually a signal about how teams are structured, and no meeting cadence fixes boundaries drawn across the work rather than around it.

If you want to build the facilitation skills this depends on, CSM Certification Trainingfrom an accredited Scrum Alliance provider covers cross team working and impediment removal alongside the framework. Request the course curriculum to see the agenda and upcoming dates, or start with our free CSM practice test.