Scrum of Scrums

… the Scrum Team working on a single product is getting bigger and needs to split into multiple teams. The Development Teams now need to keep track of progress between parts of the product and monitor dependencies and alignment issues. Issues that cannot be resolved within individual teams become a shared challenge of all teams.

✥      ✥      ✥

When more than one Development Team needs to work together to create a potentially releasable product Increment, inter-team coordination warrants explicit attention.

Multiple Development Teams working on the same product need to coordinate their work and resolve inter-team dependency issues. But you often cannot know in advance all of the dependencies and how to resolve them. Even with extensive up-front planning, during the Sprint unforeseen dependencies may emerge that need to be handled by the teams.

Preferably a Development Team should be able to completely develop a Product Backlog Item (PBI) in isolation. In that case you only need to worry about integrating multiple independent PBIs into one product. In some cases however, it is not possible or desirable for a single team to develop a PBI on its own and we end up with PBIs that span multiple Development Teams. Frequent collaboration and synchronization enable the Development Team to produce a Regular Product Increment every Sprint. Each Development Team develops independently, but all Development Teams together should produce an integrated whole.

No single team should be responsible for integrating the work of the various Development Teams, it is the responsibility of all Development Teams. If a separate team is responsible for integrating the work unnecessary hand-offs and delay on feedback is introduced. On the other hand, if no explicit team is accountable to produce an Increment, ownership and commitment suffers. Integration work is left undone. The Development Teams involved should therefore explicitly commit to perform the overlapping work.

The Scrum of Scrums is a coordinated meeting. It has the disadvantage of people tending to wait until the next meeting to discuss dependencies. When teams need to coordinate, the teams can just talk to each other without waiting for the next Scrum of Scrums.


 Introduce a recurring Scrum of Scrums event where representatives from various Development Teams coordinate to discover and resolve inter-team dependencies and impediments.

You can identify Development Team interdependencies when creating a Refined Product Backlog or during Sprint Planning. A Sprint Planning has two focus points that answer the following questions respectively:

  • What will be delivered in the Increment in the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

Answering the first question helps identify overlapping work and dependencies that need to be coordinated. The Development Teams choose which PBIs they want to implement, therefore they also know with which other Development Team they need to work together the coming Sprint to coordinate the overlapping work. In answering the second question, the involved Development Teams plan the work needed to develop and decide how to deal with the identified dependencies.

The Scrum of Scrums event can occur at a planned date and time but also emerge as frequently as needed. In the Scrum of Scrum events the participants explain:

  • What did my team do since the last time we met that could affect producing a Regular Product Increment?
  • What help does my team need to get the resolve inter-team dependencies?
  • What impediments does my team see before we meet again that prevents us to integrate our work with the other Development Teams.

Development Team members, who are actually working the overlapping work, attend the Scrum of Scrums. The Scrum of Scrums can discover new overlapping work that is needed to solve inter-team impediments and dependencies. The attendees make the newly discovered work transparent to their Development Teams by bringing it back to their team's Sprint Backlog.

Although the Scrum of Scrums is an event for resolving inter-team dependencies and impediments, their resolution should not be postponed until the Scrum of Scrums event. Impediments are worked on as soon as they emerge. Development Teams are empowered to organize themselves to get their work done and minimize dependency risk using Dependencies First. The ScrumMaster helps to remove impediments to the Development Team's progress and can invoke the Emergency Procedure as a last resort.

✥      ✥      ✥

Multiple Scrum Teams organize themselves each Sprint to plan the overlapping work and deliver Regular Product Increment. The Scrum of Scrums enables the Scrum Team to extend their Definition of Done more easily. As a result there is fast feedback on dependency problems so these can be handled in the most effective way.

The first Scrum of Scrums was implemented at IDX Systems in 1996. Jeff Sutherland was Senior Vice-President of Engineering, with Ken Schwaber on board to help roll out Scrum as a consultant. The first publication mentioning this first Scrum of Scrums was [4] and it is also mentioned in the Scrum Papers [5].

Picture from: Greg Neate, Prince Regent Swimming Pool, Brighton, May 9 2009, (Flickr). (under CC BY 2.0 license)

[1] Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, 2004.

[2] Mike Cohn, Succeeding With Agile, Addison-Wesley, 2009.

[3] Craig Larman and Bas Vodde, Practices for Scaling Lean & Agile Development, Addison-Wesley, 2010.

[4] Jeff Sutherland, "Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies." In Cutter IT Journal: The Great Methodology Debate, Part 1. Volume 14, number 12, December 2001, pp. 5-11.

[5] Jeff Sutherland, The Scrum Papers,, accessed 11 January 2017, no permalink, draft, 29 January, 2011.