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 then 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 PBI’s 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 Development Team representatives create a shared plan to discover and resolve inter-team dependencies and impediments.

You can identify Scrum Team dependencies during Sprint Planning. Sprint Planning has two focus points that answer the following questions respectively:

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

Answering the first question helps identify overlapping work and dependencies. The Development Team choose which PBIs to implement, therefore< they also know with which other Development Team they need to work together the coming Sprint to perform overlapping work. In answering the second question, the involved Development Team plan the work needed to develop and perform the overlapping work.

The Scrum of Scrums event occurs regularly and 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 effect producing an 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 organise themselves to get their work done and minimise 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.

Cesario Ramos