Advice on Conducting the Scrum of Scrums Meeting

7 May 2007

Mike Cohn
Mountain Goat Software

The scrum of scrums 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.Being chosen to attend the scrum of scrums 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. If the number of teams participating 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 scrums 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 meething.) An example of scaling to this level can be seen in Figure 1.

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.

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.”

Figure 2. Agenda for the scrum of scrums meeting.

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

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (1 ratings)


Anonymous, 5/16/2007 11:49:36 AM
I would recommend Scrum of Scrums on a daily basis for distributed teams. I was recently coaching a project with 3 Scrum teams working from separate locations (UK, Poland and India). We had local Daily Scrum followed by Scrum of Scrums by phone and this worked well for us.

At another client with co-located teams, we do weekly Scrum of Scrums which focus on dependencies between teams plus we have a daily Scrums of Scrums for integration issues.

--Rachel Davies
Anonymous, 5/21/2007 10:56:20 AM
Very good article which lets the reader know the diffrences between the daily scrum and scrum of scrum meetings. I totally agree with Mike's views on frequency and extended duration of the scrum of scrum meetings.
Anonymous, 5/23/2007 10:03:10 AM

Very good article
Anonymous, 5/23/2007 10:03:18 AM
There is very little written on scrum-of-scrums, so I found this very useful. While it was hinted at toward the
bottom of the article, are scrums of scrums used for individual team planning (so one team can
know what the other is doing - and ensure that their requirements/roadblocks are being addressed ?)

- Matt Ganis
Mike Cohn, CST,CSP,CSM,CSPO, 5/23/2007 2:31:50 PM
Hi Matt--I'm not sure if I understand what you mean about the Scrum of Scrum being used for individual team planning to ensure requirements and roadblocks are addressed. A lone team on a desert island wouldn't have a need for a Scrum of Scrums meetings. So this wouldn't be how a lone team addressed their own roadblocks. However, the Scrum of Scrums would be used among a set of teams to discuss and remove these. Team interdependencies and other similar issues are discussed and often resolved during a Scrum a Scrums.
Anonymous, 5/29/2007 7:39:30 AM
Excellent article but there is one point that may need product participation to resolve issues in Scrum of Scrums. There could be issues when two different scrum team reps may stick to their points and no one else is there to decide for them.
Lubos Mikusiak, CSM, 5/29/2007 2:37:54 PM
If the members of the Scrum of Scrums change over the time, who leads the meeting? Is it supposed to be totally self-organized? -- Lubos Mikusiak
Mike Cohn, CST,CSP,CSM,CSPO, 5/29/2007 5:21:01 PM
Replying to the two previous comments:
First, if two different participants disagree they need to work it out with the help of other participants. This is part of becoming a self-organizing team.
Second, Yes, the Scrum of Scrum participants will usually self-organize without a ScrumMaster-like role. Some Scrum of Scrums teams like to designate a ScrumMaster. My experience is that most of the time they do not. Here's why: Participants in this meeting have usually been doing Scrum for a bit and have learned how to self-organize effectively within their teams. So they come to the Scrum of Scrums with that experience and often carry it forward to not needing a ScrumMaster for these meetings.
Anonymous, 6/1/2007 5:12:21 PM
I really enjoyed reading your article. Very good and interesting insights!

On my last assignment I worked on a multi-site project with 4 teams in 4 countries (SWE, DK, NL, India). We conducted a daily scrum of scrum meeting in form of a phone conference and this worked really well for us.

The meeting was constrained to 15-20 minutes but we always reserved more time afterwards for resolving issues. Not everyone was required to stay in the meeting to discuss issues and we'd agree during the 15 min meeting who should stay on.
Mike Cohn, CST,CSP,CSM,CSPO, 6/1/2007 9:37:59 PM
Thanks, anonymous. Your constrained-but-leave-time-after approach is essentially what I do. We try to get a quick update from everyone, go over some basic sharing and then dive into specific issues to be resolved. Some people will opt out if they are not needed for the issue(s) to be discussed. But, as you point out, everyone has to agree the person can leave; it's not just up to each individual whether they should stay or go because "something else is more important." If the others think you need to stay, you need to stay.
Brian Mowbray, CSP,CSM, 6/5/2007 9:59:59 PM
Excellent article and the timing was perfect for our team. My comment is more about sharing information that posing any questions.

On or current project as an Integrator for various software components, we tried to status Scrum teams and non-Scrum teams like Operations, Configuration Management etc. We learned that trying do this was like mixing oil and water. We could not hold consistent, short status meetings when including leads of other areas. So we went back to just statusing the Scrum teams and we have a group called "Oversight" that are made up of all leads, management, and the Scrum Master (me) once a week where we surface all issues that need to be elevated from the Scrum of Scrum meetings as well as from other teams. This seems to be working mainly because it is more manageable. Scrum of Scrum meetings are 3 days a week (changed as a result of this article from 5 days) with an Oversight meeting once a week. Issues can be elevated at anytime if needed, the Oversight is the forum to track and status them among other responsibilities.

As a side note. We learned that there is way too much valuable information being exchanged during stand-up meetings to limit it to a 15 minute stand-up. Rather than not stick to the 15 minute limit, we have our standard stand-up meeting and allot an additional 15 minutes to have those conversations as a post meeting for every stand-up. This applies the same to the Scrum of Scrum stand-up.

To the comment above. I have 2 points to add. These are just my opinions.
1. We have all members remain for any additional discussions. It's a team meeting and if you already knew everything that you might learn, change proffessions and be a fortune teller because you can never predict what information sharing will expose.
2. This is more related to the daily scrum meeting than Scrum of Scrums but in order to ensure JIT design, development and test, you typically want all members to remain to support their relative areas so that whatever direction is decided everyone knows what it is and from their perspective.
Tara Lee Whitaker, CSM, 7/11/2009 5:22:27 AM
Great article, Mike.

We have five core teams, some of which are further divided into smaller teams. In an effort to keep the SoS short and useful, we've recently introduced an Epic Board into the mix. This board is similar to a Task Board, but spans sprints and teams. This visual representation of our programme has added context to the questions you describe above:

1. What has your team done since we last met? -
We check these off
2. What will your team do before we meet again? - We re-arrange the contents of coming sprints if there are any glaring issues
3. Is anything slowing your team down or getting in their way?
4. Are you about to put something in another teamΓÇÖs way?
Mike Cohn, CST,CSP,CSM,CSPO, 7/12/2009 6:43:11 PM
Hi Tara--
This sounds like a very interesting approach. I'm a fan of anything that makes things visual. Thanks for sharing this.
Frank Klosek, CSM, 2/1/2010 8:29:28 AM
Hi, very interesting. My portfolio is a bit different. I've to manage one team, where marketing (product owner) and scrum master (me) and one technical expert are located on one site and the operational team with a local team leader is located in Bangalore. I'm looking for advices on how to best start up a SCRUM setting for this layout.
Chandresh Patel, CSM, 6/17/2010 6:52:24 AM
I have query. our product owner is in US and scrum master in india. we are doing SOS (different team of our project) on every tuesday. in that different team scrum masters, produtct owner, Manager,one developer of our team,one tester of our team and one tech writer of our team are participated in this SOS. in that we are discussing the issue from different teams only.

we have another SOS (thusday), which involve product owner, one developer of our team,one tester of our team and one tech writer of our team. in that we are dicussing only team realted issue or status or discussion only realted to the
user stories we are working on. It is good.

but now, our scrum master is planning to schedule same SOS (thusday) involve complate team (size 15). and as per my thinking it is not adviceble. as a team we don't want this type of SOS. we are westing the time of all 15 team members at 6:30 in the evening. It generally goes to 1/2 to 1 hours. if the sscrum master and product owner wants to do it then it is not SOS. it should call team meeting. we are misused the name of the SOS. what do you say about it? Please give your advicible comment ASAP. I would like to stop this type of things that team don't want.
Mike Cohn, CST,CSP,CSM,CSPO, 6/17/2010 9:45:01 AM
Hi Chandresh--
I'm with you. If the team doesn't want that meeting (and they are experienced enough to make such decisions intelligently) then the ScrumMaster should find another of getting whatever information he needs. I tell ScrumMasters their job is to be a bulldozer the team--they are to bulldoze crap out of the way of the team so they have time to do their jobs. This sounds like a ScrumMaster bulldozing extra into the way of the team.
Grant Marotta, CSM, 4/12/2011 1:58:44 PM
We have about 10 Agile teams (and counting, we're about 3 months into it) and are now starting SoS meetings. One problem is getting a volunteer to attend each SoS (we have them twice/week). As a Scrum Master (me) I really want someone to step up but can I or the team force one of the team members to attend?
Also, getting inputs for the SoS backlog (at least getting it started) is an issue. Any ideas?
Mike Cohn, CST,CSP,CSM,CSPO, 4/12/2011 2:47:36 PM
I suggest having the team vote on who will go for the next 2-3 months (pick a duration). Say it can't be you since you've been doing it. If there are no items for an open issues backlog, I wouldn't worry about it. They'll arise as needed later but it is surprising you don't have many coming in with 10 teams.
Debayan Gupta, CSM, 7/29/2011 12:58:29 AM
Hi, initially we started our SOS with a single participants from each team who is not a scrum master and discussing the 4 questions mentioned by you in this article. But many felt that it is a duplication of updating the status in both scrum and sos and there are only a few occasions when one team's update helped other team in progressing. Also for blocker issues, one can immediately remove the same by contacting appropriate person, rather waiting for SOS to happen. Currently, only blocker issues, if any, are discussed and other topics are discussed on need basis. Also, management felt that non SM participants were not appropriate to attend this meeting and instructed SMs to attend the meeting. Could you please let me know whether we are practicing proper SOS or any specific change/improvement is required?
Pradeep De Silva, CSM, 5/2/2012 10:15:25 PM
Hi Mike - just wondering if you would recommend a scrum of scrums if there are no interdependencies between the scrum teams? The situation is that four different teams are delivering a program of work for a Product Owner, the main challenge being balancing operational priorities with project work within the scrum teams themselves. I guess a SoS could provide an opportunity to share resources between the teams. Cheers
Sangeeth Jagadish, CSM, 2/19/2013 10:53:11 PM
I have scrum teams in Costa Rica,India and UK.

The UK team composed of mainly the business and the product owner.

How effectively can i conduct a scrum of scrums.

The teams are not at all similar.The team in Costa Rica is a older team but the team in India is just about to onboard the project after a Due Diligence phase.

What are the potentials problems that might come across in the SOS in this case?

You must Login or Signup to comment.