Skip to content

Scrum in practice: the Scrum of Scrums meeting

Scrum in practice: the Scrum of Scrums meeting

by Jim Bowes

What is a Scrum of Scrums meeting and how does it fit into the Scrum methodology?

Scrum is a popular Agile methodology, most frequently used by software development teams, allowing for closer collaboration between the developer and the business.

The Scrum of Scrums (SoS) meeting is a technique used when scaling Scrum in organisations with large development teams working on a single product or product family. It's intended to help coordinate and synchronise the work of multiple Scrum teams so they can achieve their common goals more easily.

Keeping Scrum teams manageable

The general consensus is that Scrum teams operate most effectively when they have between three and nine members. When teams are too small they don’t complete an optimum amount of work in a Sprint, or benefit from the cross functional nature of the team. As teams get too large, self-organisation becomes practically impossible.

So what happens when, to complete all the work required, you need a large development team working on a single product? Rather than allowing teams to grow to the point where they’re no longer realising the benefits of Scrum it’s better to have multiple teams and distribute the work among them. But for this to work, you need an effective way to communicate between the teams.

The Scrum of Scrums meeting is a regular meeting which aims to do this coordination work. It is attended by representatives of each Scrum team and is based on the format of the Daily Scrum Meeting, where each team takes it in turn to say what they’ve been working on, what they’re about to work on and what they need from the other members to proceed.

Who attends the Scrum of Scrums?

There has been some controversy around the Scrum of Scrum meeting in terms of who should attend it. The heavy hitters in the Scrum world insist that the representatives of each team at the Scrum of Scrums should be technical members of their team, not ScrumMasters or Product Owners.

The reasoning is that the Scrum of Scrums meeting should adhere as closely as possible to the foundational principles of Scrum i.e. it should help the teams move forward together towards their shared goals. It shouldn’t turn into a status report to stakeholders and it shouldn’t leave all the responsibility of coordinating the work of the various teams with the ScrumMasters. The ScrumMasters should be coaching the teams towards self-organisation, not doing all the organising themselves (or else they run the risk of turning into Project Managers).

In practice though, it’s often sensible for the ScrumMaster to attend the Scrum of Scrums. In fact, it’s often difficult to keep them away since they want full visibility of any potential impediments. They’re also equipped with the necessary skills to facilitate these meetings.

If the ScrumMasters do attend the SoS — and perhaps take on a rotating facilitation role — it often makes sense for them to do so as a secondary attendee and to let another member of the team participate in the actual work of coordination.

The role of SoS in scaling Scrum

The SoS technique can be scaled up for use in organisations with hundreds of developers. Again, rather than letting the SoS team become too large to self-organise, it’s better to send representatives from several Scrum of Scrums to a Scrum of Scrum of Scrums and so on.

However, while the SoS technique can be invaluable for scaling Scrum in a large organisation it’s far from sufficient in and of itself. Several other techniques for scaling Scrum might need to be employed such as uniform definitions of 'ready' and 'done', meta Scrums (meetings where product managers make decisions about product plans, to feed the backlogs of the Scrum teams) or even incorporating elements of XP. Embellishing Scrum with add-ons like this, to make it more suitable for particular environments is often called ScrumAnd.

There are also some specific frameworks designed for scaling Scrum in an enterprise environment, e.g. SAFe — the Scaled Agile Framework.

Jim Bowes's avatar

Jim Bowes


Contact Jim

Our recent insights

Agile Pillar Content (1)

A comprehensive guide to Agile project management

Our guide to the transformative power of Agile project management and how adaptability, collaboration, and continuous improvement drive success.

What government registers can learn from thrifting apps

We explore the parallels between thrifting apps and government registers, and how user-centric design and data quality are key for successful outcomes.

Place and infrastructure: thinking about digital transformation in a new way

Digital transformation is more than gadgets or sensors—it's about the intentional and adaptive design of policy, planning and project delivery to achieve user and economic outcomes.