Advice on Conducting the Scrum of Scrums Meeting

The scrum of scrum meeting is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.

Imagine a perfectly balanced project comprising seven teams each with seven team members. Each of the seven teams would conduct (simultaneously or sequentially) its own daily scrum meeting.

Each team would then designate one person to also attend a scrum of scrums meeting. The decision of who to send should belong to the team. Usually the person chosen should be a technical contributor on the team—a programmer, tester, database administrator, designer, and so on—rather than a product owner or ScrumMaster. This group then represents the ideal scrum of scrum team size.

Being chosen to attend the scrum of scrum meeting is not a life sentence. The attendees should change over the course of a typical project. The team should choose its representative based on who will be in the best position to understand and comment on the issues most likely to arise at that time during a project.

For instance, early in a project the issues brought up at the scrum of scrums meeting may center mostly on technical issues or user experience design. Teams may opt to send someone strong in one of those areas to those early meetings. Later, issues may center around how to collaborate on testing, and so testers will be the more likely participants.

The scrum of scrum team size also depends on the number of teams participating. If that number is small, it may be acceptable for each team to send two representatives—a technical contributor, as described above, and a ScrumMaster—if the teams desire. I tend to do this only when there are four or fewer teams, which keeps the meeting size to eight or less.

The scrum of scrum meetings can be scaled up in a recursive manner. Imagine there are seven scrum of scrums meetings occurring in your organization. Each contains a representative from each of seven teams (as in the previous example).

The work of the seven scrum of scrums meetings can be coordinated through an even higher level meeting: what might be called a scrum of scrum of scrums. (It isn't usually called this, though, because things start to sound a bit silly at some point. Scrum of scrums often suffices even for these higher levels of meeting.) An example of scaling to this level can be seen in Figure 1.

Scrum of Scrums image
Figure 1. The scrum of scrums meetings can be scaled indefinitely through multiple layers.


The frequency for scrum of scrums meetings should be determined by the team. Ken Schwaber has suggested that these meetings should occur daily, just like the daily standup or daily scrum. He also suggests timeboxing the meetings to last no more than fifteen minutes.

My preference is to hold potentially longer meetings less frequently. I find that two or three times a week is often sufficient. This makes a Tuesday-Thursday or Monday-Wednesday-Friday schedule appropriate. While a scrum of scrums meeting will often be completed in fifteen minutes as Schwaber suggests, I recommend blocking thirty or sixty minutes for them on the calendar. Here’s why: A common rule about daily scrum meetings is that they are not for problem solving; if a problem is identified it is usually addressed after the daily scrum (often immediately after).

This rule doesn’t apply to scrum of scrums meetings. If a problem is identified and the right people to address that problem are together, they should address it then and there. A problem that has risen to the attention of the scrum of scrums meeting participants is often a significant problem that could be affecting the work of up to 100 people. It deserves to be addressed and, if possible, resolved in that meeting. Therefore, while many scrum of scrums meetings will be over in fifteen minutes, always budget more time to address potential problems.


A good agenda for the scrum of scrums meetings is similar to the standard agenda for the daily scrum. In that meeting each team member is asked:

  1. What did you do yesterday?
  2. What will you do today
  3. What obstacles are in your way or slowing you down?[1]

Because the scrum of scrums meetings may not be daily and because one person is there representing his or her entire team, these three questions need to be rephrased a bit. I also find it beneficial to add a fourth question:

  1. What has your team done since we last met?
  2. What will your team do before we meet again?
  3. Is anything slowing your team down or getting in their way?
  4. Are you about to put something in another team’s way?

This last question can be extremely helpful when coordinating the work of multiple teams. Common answers are things like, “We’re about to do a major check-in of the payroll processing code. We had to restructure the version control repository to do that, which made us rewrite a big part of the build script. But we’ve thoroughly tested everything and don’t expect this check-in to break anything.”

Well, we all know how that story ends. Having advance notice of potential impediments like this can be very helpful. The scrum of scrums meeting starts with each participant answering these four questions. Like the daily scrum, this part of the meeting is meant to be fast-paced and fairly short.

One technique I’ve found helpful in achieving this is adopting a rule that no names can be used. There are two reasons for this. First, leaving out names keeps the discussion at the appropriate level of detail. While attending the meeting, I want to hear about each team, not about each person on each team.

Second, too many people equate importance with how long they talk during a meeting. Removing the ability to describe the activities and plans of each person on a team goes a long way to keeping this part of the meeting short. During this part of the meeting problems can and should be raised, but solutions should not be discussed and considered until after everyone has had a chance to answer these four questions.

After everyone has answered the initial questions, the focus of the meeting shifts as shown in Figure 2. Participants address any issues, problems, or challenges that were raised during the initial discussion or previously identified and maintained on a scrum of scrums backlog.

This backlog is analogous to what might have been called an issues list on a traditional project. It is a simple list of outstanding issues that participants in the scrum of scrums meeting either feel responsible for addressing or that they are tracking for some other reason. (For example, the issue is being addressed in another scrum of scrums meeting but this team needs to know the resolution.)

Often a simple, low-tech tracking mechanism is adequate for this backlog. Many teams use a large piece of paper hanging in a team room. Some also use a spreadsheet or wiki.

Agenda for the scrum of scrums meeting.
Figure 2. Agenda for the scrum of scrums meeting.

One last difference between the daily scrum and the scrum of scrums meetings is that while most scrum of scrums meetings maintain a backlog of issues and problems to address, very few conduct formal iteration planning and iteration reviews analogous to what the individual teams are doing. Participants in the scrum of scrums meetings are first and foremost individual contributors on their teams.

The higher-level scrum of scrums is a more transient group; each iteration has the potential to bring a new set of attendees. The iteration planning and commitments that drive a project forward belong, for the most part, at the individual team level. Some scrum of scrums may conduct iteration planning meetings, but if they do, these are usually much less formal than what the individual teams do and consist of general goals for an iteration such as “we’ll address this issue, that issue, and resolve that other problem.”

1. Rising, Linda, “Agile Meetings.” STQE Magazine, May/June 2002, pp. 42-46.

Download Scrum Master Guide

Download Scrum Master Guide

Get a free copy of Situational Scrum Mastering: Leading an Agile Team

Get my free guide now!


Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at If you want to succeed with agile, you can also have Mike email you a short tip each week.


Stephen said…

I understand that it is not typical for Product Owners to attend scrum of Scrums, but this is potentially missing a great benefit in identifying patterns of dependencies and allowing prioritisations to be adjusted accordingly

Mike Cohn said…

Hi Stephen—
I recommend that product owners attend daily scrums and that the chief product owner or product line owner attend the scrum of scrums. You’re absolutely right that this is necessary for discussions of priorities and dependencies that may arise in those meetings.

Raja said…

Just wanted to know if Scrum of scrums and Meta Scrum means the samething. In agile alliance
it points out be the same…but I found quite a few papers where it is suggested that Meta Scurm should happen once in a month with chief product owner and chief scrum master. So little confused if the agile alliance page captured it corrcetly.

Mike Cohn said…

Hi Raja—
“Meta-Scrum” is not a standard Scrum term. It used to be used by some people to be equivalent to Scrum-of-Scrums but “scrum of scrums” has because the standard term for that meeting. If Meta-Scrum were a standard term, I can’t see that it would refer to a once a month between between product owner and ScrumMaster. (If those two meet only once a month, the project has a bigger problem than what to call their meeting!)

doomoo said…

Strange that your name isn’t linked, would be nice to have an index of all articles by an author. 😊

mikewcohn said…

Essentially all the articles are by me (or by me plus a co-author) so you can click on the “Articles” link in the breadcrumbs above and see all the articles.

Rohan T. D. said…

Oh ok. Thanks! 😊

Scott MacIntyre said…

Hi Mike. So when impediments are brought up and recorded in the SoS, are they chased down and resolved by the SoS team? If so, would it not be a better use of the developers’ time to develop, and hand off the impediment list to Scrum Masters?

mikewcohn said…

An issue raised in the Scrum of Scrums should be resolved in whatever manner is most appropriate. It could be someone scheduling a meeting for the database people on the project to get together and figure out which version of Oracle they’re using. Or it could be one participant taking on the issue and saying “I’ll go talk to that one VP and get us an answer.” Or it could be that one participant relaying the need to someone not present to have them solve the issue (if that person is best suited to that).
I’m not a big fan of an “impediment list” ever—you shouldn’t have so many impediments you need a list. I’m definitely not a fan of an impediment list at the Scrum of Scrums level. They may be addressing issues but hopefully most of them are identified and resolved before they impede anyone.
But, perhaps guessing at the true intent of your question: No, I wouldn’t want programmers resolving many impediments unless they were ones that only programmers could resolve. Most should be addressed by a ScrumMaster.

Patrick said…

Hello Mike,
In our company, we are presently putting in place a program managment plan with over 24 different projects.  It is a big operational change within the company, since poeple were working in their confort zone by process and not projects, now with a team leader and SME team members.  I want to put in place stand up meetings (scrum) to help out.  At the same time have other options regarding meeting minutes.  Do you think scrum is a good approach for the change?  Do you have tips on how to start this?  At the same time do you have tips regarding meeting minutes?

mikewcohn said…

Hi Patrick—

I think I understand what you’re asking. If so, I think you’ll find the first 100 pages of the Succeeding with Agile book helpful. That is about how to use Scrum to manage organizational change projects. It works well.
I don’t have anything particular to say about meeting minutes. I suspect a lot of agilists would be opposed to them, but I find them very helpful. If a meeting is worth having, it’s worth documenting key decisions (or actions agreed upon) in the meeting. I find that without that, too often I will forget what we decided. I’ll remember we discussed two options but I won’t remember which we decided to pursue. So I’m a big fan of meeting minutes as long as they’re kept lightweight.

Daniel Zacharias said…

Hi Mike,

How are you?

  Our team started small, but it grew up to 18 team members. We started splitting into 3 teams, each with their own daily meetings. However, our planning meetings and retrospective meetings are attended by all 18 members. We’ve done our best to timebox those meetings to a reasonable length. Currently, our planning meetings last more or less 3-4 hours; which is not that bad, however we struggle constantly with this.
The reason for having one planning meeting for all teams is that we share the same backlog (and same PO), and I wouldn’t feel comfortable in splitting the backlog into areas or modules: I don’t want that team members get specialized on only one module/area. Plus, depending on the moment, one of the modules may require most of the work based on the priorities, and all three teams will work on that module.

Do you think we should try to split our planning meeting? (i.e. that each team - whose team members rotate each sprint, btw - have a separate planning meeting?)

Thanks in advance!


mikewcohn said…

Hi Daniel—
Yes, I would split. Three-to-four hours is a long meeting (depending on the length of your sprint; not stated).
I understand the fear of people becoming too specialized but there may be some value in allowing people to work with the same teammates longer than one sprint, as it sounds like you do now. I’m not a fan of reconstituting a team each sprint—it takes time to learn to work well together.
I’m a fan of a technique called “The Big Room.” It’s described in Succeeding with Agile and in my video course on Agile Estimating and Planning. Plus it’s probably in some of the scaling presentation PDFs on this site. The basic idea would be to bring all 18 into one room. Split into three groups of six (or similar) and have each group take part of the room. Have each start planning independently but with full freedom to yell across the room, “Hey, Daniel! We need you for a few minutes!” or to walk over to another group and hand them a task that needs to be done by the other team (and then checking later that the team is willing to take on that task). This meeting can start with some announcement from a Chief Product Owner to the full team, etc.
I suspect this will get you the advantages of being a big team and some of the speed of being smaller.
You didn’t ask about retrospectives but mentioned them so I’ll do the same: I’d give each team a mix of opportunities for one-team retrospectives and all-teams retrospectives. That is, do every other one with 18 people and the others in smaller groups. But if you continue to remix teams every sprint, the one-team retrospectives can be eliminated.

Daniel Zacharias said…

Hi Mike,

  Thanks for your answer! I’ve proposed the changes our last retrospective, and the team really liked the idea. We’re going to start with a fixed team for at least 2 sprints (each sprint is 2 weeks long); and then we’ll analyze how and if we mix the teams.
We’ll also have a separate planning and retrospective, but using the ‘big room’ method.  For the retrospective, the first part of the meeting will be per team, and at the end we’ll leave some time to discuss common topics all together.

The main challenge is to come up with a criteria to split the backlog into 3 views (for each team). For instance, some of the items are not anyone’s favorite (the reports… who would have guessed 😉), so the idea of assigning report PBIs to the same team is not an option. I’ll try to come up with a logical partition so that every team deals with those unwanted PBIs, but following some criteria (again, it’s not so simple as split them by module).
Other PBIs are not easily identifiable with a single module/team or are too generic. So it’s not trivial -at least now- how to assign them into a teams backlog view. Our first approach will be to split them arbitrarily into the team views. We’ll see how this goes.  I think there’s still this fear of specialization that we’ll have to overcome.


mikewcohn said…

You’re welcome, Daniel.

Michael said…

We currently have five scrum teams.  The scrum masters get with the scrum of scrums master weekly to hold their scrum of scrums.  They answer the questions you’ve laid out above.  I, the chief product owner, am looking to hold a scrum of product owners meeting following the scrum of scrums meeting.
1) How often would you recommend this meeting occur?  I see that our scrum of scrums is already a bit less frequent than you suggest, but we have other meetings for our non-scrum teams to keep them informed that our scrum masters also attend.  I think these help fill in the gaps.
2) What agenda would you propose? The same agenda? My goal is for the POs to know what is going on with the other scrum teams, to be aware of possible interference a scrum team may be generating for a different team, and to be aware of impediments that need to be solved at our level.

mikewcohn said…

Hi Michael—
Normally there is a reporting relationship between a Chief Product Owner and product owners responsible for portions of the product. The meetings you’re describing are really just that leader’s staff meetings. It’s hard to suggest a specific frequency for those meetings. It depends on size of the project, complexity of the project, relatedness of the work, experience of the product owners working together, the speed inherent in the product domain, and so on.
Personally, I’d rather schedule formal meetings a little too infrequently but have easy communication channels so items that come up between meetings can be easily discussed. That also makes it easy to discuss an issue with just the subset of product owners necessary.
As for the agenda: I don’t think you need to start with quite as much reminding each other of things at the start of the meeting. That’s more needed in a true scrum of scrums when participants change. With a staff meeting like this, I’d do a bit of that each meeting but I’d do most of it in the first staff meeting after a sprint planning session.
I’d then devote time to open issues (as in a scrum of scrums). As a product owner meeting I would also spend time talking about upcoming product backlog items, particularly relatedness and priorities of items. You’ll probably be able to identify a time horizon you should be looking ahead—e.g., you may find these meetings work best when looking ahead three sprints. That gives you time to try to resolve impending issues, make decisions, etc. before those affect the team. Of course, the less far ahead you look the better (in some ways) but it becomes hard to steer the project if you’re looking only a day ahead.
Good luck with your project.

Richard Jacobs said…

Hallo Mike,
I thought the same post that Raja is referring to has been commented by Jeff himself. Unfortunately the site was updated, deleting all comments at the same time. So I’m still looking for an alternative source posted by Jeff (there is some information at but I can’t trace it back to Jeff directly) . In his post Jeff was very clear about a meta scrum and a scrum of scrums NOT being the same. The Scrum of Scrums is indeed an operational mechanism to align teams about there daily operations while the Meta Scrum is a funding mechanism for the PO to do stakeholder management towards the rest of the organisation i.e. with other PO’s and CPO, etc. Therefore it is not necessary to do a Meta Scrum on a daily base.
I hope this was a bit helpful although it’s an old thread 😉
Kind regards.

Mike Cohn said…

Thanks, Richard. I’ve never heard anyone except Jeff ever refer to a meta scrum so I’d refer all questions on it to him. But thanks for your clarification.