How and Why to Build a Scrum of Scrums
Once a project gets big enough to need multiple Scrum teams on deck, many companies choose to start running Scrum of Scrums (SoS).
Think of it like daily Scrum, but for multiple teams, where cross-team issues are identified and accounted for.
As intuitive as it seems to run Scrum of Scrums—it really is a simple extrapolation of the daily Scrum—you want to make sure you’re setting yourself up for success. In this post, you’ll find everything you need to start an SoS that benefits every team involved.
What is a Scrum of Scrums?
Scrum of Scrums is a meeting between representatives from several Scrum teams working on one sprint. They get together to assess what they’ve done, what they are working on, and the problems they foresee. Project-level issues that would be impossible to spot from the individual team perspective can be flushed out en masse.
It’s the most collaborative way to make sure each Scrum team is working in concert.
More importantly, holding a Scrum of Scrums routinely can help teams synchronize their work as the sprint progresses. This is especially necessary considering:
- Dependencies: where the work of one team is contingent on the work of another
- Integration: where any functionalities the teams are developing need to work together
In a nutshell, a Scrum of Scrums helps keep all teams on the same page and their resources allocated productively.
Who attends the Scrum of Scrums?
You have some flexibility here. You may even want to send multiple representatives, though it’s important not to overload the Scrum of Scrums. The more people who attend, the less each one can say.
The meeting needs to stay short and focused, and to make that happen you need to send the right representative(s). Let’s go around the Scrum team and consider the pros and cons of each role turning up.
Scrum master
Having the Scrum masters attend Scrum of Scrums is the most common set-up. These individuals are already tasked with maintaining a bird’s eye view of the team, its progress, and the direction it’s heading. They’re probably in the best position to share information on each team’s situation.
That said, if Scrum masters and only Scrum masters attend the SoS, it can generate blind spots where technical issues are concerned. They might not be equipped to characterize them. There’s also the possibility that the Scrum of Scrums devolves into a traditional project management group that saps the individual Scrum teams’ important ability to self-regulate.
Product owner
Product owners may have valuable insight to add to a Scrum of Scrums, but you don’t want to send the PO only. Their backlog knowledge can help avoid duplication of work and standardize the definition of “done” across teams, but as with daily scrums, this is information usually left for the Scrum master to relay.
Note: What you might want to do, though, is hold a separate “Scrum of Product Owners” to realign teams on a single, prioritized backlog. It doesn’t need to be regular—just a one-and-done or maybe quarterly chance to calibrate the company’s overall vision for the product once you’ve grown enough to start looking at cross-team issues.
Development team
There are definite benefits to involving the technical acumen of each team’s engineers. Sending developers alongside Scrum masters makes sense if you need to address technical concerns between teams.
The person you want in the meeting is the one who can best convey all current issues to the Scrum of Scrums. For example, testers and UX designers might be closer to these issues as release approaches.
What about rotating the representative for Scrum of Scrums?
I’ve seen some teams do this successfully. Often, they will send the Scrum master plus a different member of the development team each time to keep individual teams tuned in to the larger effort of integrating different components of the sprint.
In the spirit of self-organizing, why not let the teams choose their representatives? This can work well if the team has a strong understanding of what information to contribute to the Scrum of Scrums. (Newer teams might benefit from a Scrum master-assigned rotation until they get to know how each other works.)
Who facilitates Scrum of Scrums?
For small and collocated Scrum of Scrums, it might be easiest to have the group self-organize. Alternatively, you could rotate representatives, tapping a different facilitator every sprint. In larger or distributed environments, though, you’ll want to designate an official facilitator.
This may be someone at a higher level than the teams, like a product line owner or a program manager. Pick someone with project management soft skills—communication, negotiation, leadership, etc.—who can ensure the meeting accomplishes what it needs to in the quickest amount of time.
Timeboxing Scrum of Scrums
The session length of your Scrum of Scrums will depend on the number of Scrum team representatives who attend. You will run into other variables, but keep your eyes on the prize: coordinating efforts across teams to deliver functioning and integrated product increments.
To determine the proper timebox, it might take trial and error. Inspect past Scrum of Scrum meetings and adapt as need be. Was there enough time for all teams to share their input and visualize the total scope of the project? Is there stuff you can leave for the individual teams to figure out?
Remember, the Scrum of Scrums is modeled after daily Scrum—also known as the daily standup because so many teams stay standing. It’s only for 15 minutes. Often the scope of Scrum of Scrums requires more time than that, but try to keep to the same level of brevity and momentum.
The ideal Scrum of Scrums frequency
Similar to timeboxing, work backward to figure out how often you should hold Scrum of Scrums.
Some people hold it daily for the routine, or because there’s significant overlap between the work of individual teams. This is when you can afford to be brief—typically 15 minutes. Others decide to hold longer Scrum of Scrums, but only two or three days a week.
Of course, you can and should switch things up with project demands.
Example: a company holds daily Scrum of Scrums at the outset of a project, when big decisions are being made, and again at the end, as release approaches and teams need to coordinate integration. Besides those bookends, the Scrum of Scrums switches to a Monday-Wednesday-Friday schedule.
If the day-to-day progress of most of your Scrum teams doesn’t affect the work of the others so much, you can get away with holding Scrum of Scrums less often. You can always ramp it up for crunch times.
A sample Scrum of Scrums agenda
At the end of a Scrum of Scrums, representatives need to leave with an understanding of work to prioritize to maintain the overall pace. Figuring out which tasks depend on others will help root out potential inefficiencies and integration issues before they disrupt the sprint timeline.
That means each representative should be ready to answer the following questions:
- What has my team completed since the last SoS?
- What impediments did we come across and how did they affect the work?
- What are we expecting to complete before the next SoS?
- What impediments do we foresee, and how will they affect other teams?
The frequency and timebox of your Scrum of Scrums will dictate the level of detail you can get into.
It’s all about information sharing. Team representatives can exchange scripts and tools if helpful. It could also be a good time for a quick Mad, Sad, Glad exercise to gauge confidence levels in the project and whether people believe they’re on track. Just be sure to keep the agenda trim and routine.
Tip: Use burndown charts to capture the output of each Scrum of Scrums. That way each representative returns to their team with a summary of progress.
By now you might be wondering: which comes first in the day? Daily Scrum or Scrum of Scrums?
When daily Scrum comes first, it means the representatives arrive at the Scrum of Scrums with a fresh understanding of where their team stands. But they’re not likely to meet with their own team for another day at least. If anything urgent comes up in the Scrum of Scrums, the representative will have to communicate it to the team another way.
Alternatively, running Scrum of Scrums before each team meets for their daily Scrum means representatives join their own teams with up-to-date info on project-level goals and roadblocks. This can really help some Scrum teams plan their day’s work. But what if the daily Scrum reveals urgent team-level impediments that could impact the other teams?
There are solid reasons for each case. But whichever order you choose, I would hold them in quick succession. Also, come up with a way to account for any urgencies: maybe you have a dedicated Slack channel for those kinds of alerts.
So, is it time for you to build a Scrum of Scrums?
As soon as you have more than one Scrum team working on a project, you are going to need some kind of cross-team coordination. Face-to-face is generally better than Slack.
And a handpicked Scrum of Scrums is infinitely better than a giant daily Scrum. Let’s say you have three Scrum teams. Even if they’re small (typically five to nine people), imagine getting the entire group together in one room. What’s going to happen?
Non-officially, there will probably be a few speakers from each team anyway, with the rest just sitting silent. Odds are it’s not the most efficient use of everyone’s time.
Yep—it’s time for a Scrum of Scrums. Instead of trying to cobble together ideas in a full-team forum, it makes a lot of sense to embrace the power of small groups and short meetings. Just like the daily Scrum, one of the main goals of Scrum of Scrums is to eliminate the need for all other meetings.
Final thought: Inspect & adapt as you scale
Building a Scrum of Scrums can help you move quickly without traditional project management methods hanging over your teams. It’s inherently agile. Naturally, it takes introspection to work.
Try to bake the usual inspection and adaptation into the process—not just to establish your timebox, but to figure out what to improve. As part of your retrospectives, for example, make sure Scrum masters are getting feedback from their teams about how the SoS is helping them function. As I talked about in an overview of a good retrospective example, these meetings need their own retrospectives too.
Also get feedback from the Scrum of Scrum representatives. Are they seeing the benefits? If not, don’t give up on it before making some tweaks.
