Scrum of Scrums. Work Together with Multiple Scrum Teams.
What is the Scrum of Scrums? And how can it be implemented in large projects with multiple teams?
If the number of team members is too large, then form more Scrum teams. So that they are all on the same page, Scrum of Scrum meetings take place.
The Scrum of Scrum meetings can take place daily, or in another time cycle. It is not determined who will meet from the teams. More than one person from a team can also be sent.
Scrum of Scrum meetings can also keep going: representatives are again selected from the Scrum of Scrum meetings to meet with representatives of other Scrum of Scrums. It is important that there are not more than nine people present.
An essential feature of Scrum is the suggested size of the development team: in order to communicate efficiently, a maximum of nine people should work together. But what about if an organization is large and multiple departments are developing a product? If 20, 50 or 100 people are working parallel and the participating people are not only distributed over offices and levels, but also over buildings or even countries? How can requirements be managed and communication between the teams ensured?
What Is the Scrum of Scrums?
In accordance with the agile principles, Scrum suggests a daily face-to-face meeting – a daily Scrum. This meeting takes place only within the team itself. Whether it is still possible to do it face-to-face depends on the team. So that the different Scrum teams are on the same page, the Scrum of Scrums comes into the picture: Each team prepares one or more people who then meet and report on their team’s status.
A short definition of Scrum of Scrums:
If a Scrum team becomes too large, form more teams. The Scrum teams work with their own team and sprint backlogs and hold their own daily Scrum meetings.
To keep everybody on the same page, a Scrum of Scrum meeting takes place between the teams.
Who Meets in a Scrum of Scrums?
Exactly who meets in a Scrum of Scrums meeting is not set in stone. Depending on the theme, teams can send different experts. For example, an UX expert and then a tester. How many people the teams send to this meeting is also not set. But the same rule applies here: no more than nine people can be there in the end.
The Scrum of Scrums can also continue on higher levels. Theoretically, these meetings are called Scrum of Scrum of Scrums but this is not really done. The meetings can take place not only across teams, but also between experts. For example, between the product owners.
How Often Do They Meet?
The frequency of Scrum of Scrum meetings depends on your business. According to theory, at the end of the daily Scrum, a Scrum of Scrums meeting should take place – these are short Scrum of Scrums, for which only about fifteen minutes are planned. However, often Scrum teams realize that they don’t actually need to meet so often. Or that the higher up these meetings take place, the less often they are needed or even possible. For many large organizations, a frequency of two to three times a week has been tried and tested. Many start there with a duration of longer than an hour, in order to be able to discuss problems in detail. These are long Scrum of Scrums.
What Is Discussed?
In a Scrum of Scrums, similar questions to the daily Scrum are discussed. Because the meetings normally don’t take place every day and each team has to be represented, the three standard questions are formed differently and increased by one:
- What has the team achieved since the last Scrum of Scrums?
- What will the team achieve before the next meeting?
- Are there obstacles that stand in the way of the work of the team?
- Could something that one team does be a hindrance to another team?
The themes – especially problems – can also be recorded in a Scrum of Scrum backlog.
Scrum of Scrums Summarized
- A meeting between members of individual teams
- Daily or with a longer time intervals (e.g. multiple times per week)
- No specification of who meets each other from the teams
- Can be carried out at higher levels (Scrum of Scrum of Scrums)
- Duration of a meeting: about fifteen minutes to one hour
- Answer four questions that concern the state of the team
How to Work Efficiently with Teams in Practice
Find out more about agility with objectiF RPM or objectiF RM »
And how are the other Scrum meetings carried out?
1. Daily Scrums take place in each team.
2. Sprint reviews should be carried out with all member of each team. For organizational reasons, this can take place on multiple levels.
3. Sprint retrospectives are carried out with the teams or as a Scrum of Scrum.
How Does the Implementation of Requirements with Multiple Scrum Teams Succeed?
Domain/Product Backlog
Just like Scrum in small frameworks, the requirements for a product are collected in a central product backlog. If there is one backlog per subject area, then these are sometimes called domain backlogs. All the requirements of the highest technical level – the features – land in the product or domain backlogs. Epics come from these: refinements that derive from features but are still too extensive to directly implement. If user stories can already be derived, then these are also added to the product backlog.
Release Backlog
Then, features, epics and user stories are divided into releases. A feature should be completely realizable in a release, whilst a user story should be implemented in a sprint.
Team Backlogs
Now one big challenge holds true: if a release’s requirements are immediately distributed into a backlog, how can you make sure that the teams are not accidentally working on the same user stories? Of course, everything can be communicated: indeed, the danger of it is high. Above all when the Scrum teams are in different countries and conversation is harder. That is why sharing requirements into Scrum team’s release backlogs has been proven. That way different team backlogs arise and the responsibilities are clearly regulated.
Sprint Backlog
Each Scrum team plans their own sprint backlog based on their team backlog. If there are dependencies on other teams’ requirements, this affects the prioritization: for example, a requirement might be placed further towards the botton of the list in accordance with its business value. But because another team depends on its implementation, it moves further toward the top. At the end of the sprint, each Scrum team has supplied a part of the product increment. The system under development grows incrementally through individual teams’ results.
Product Owner
- Has to manage a bigger workload
- Has to be present in all meetings
Scrum Master
- Has to solve problems affecting all teams
- Has to solve dependencies on other teams
Development Team
- Has to work less self-organized
- Is large or distributed and has to communicate efficiently despite this
Sprint Planning
- Goals have to be determined with regard to the other teams
Sprint Backlog
- Electronic communication paths have to be set up
Product increment
- Dependencies of other teams have to be solved
Daily Scrum
- Team members are distributed, face-to-face communication is no longer possible
Sprint Review
- Has to be explained whether the whole product or only the team product needs to be considered
Sprint Retrospektive
- Cooperation is necessary to solve problems
Work with Scrum teams
In a large organization and with diverse Scrum teams, you work with thousands of requirements. You have to plan the product and domain backlogs, break features down into epics, and then refine user stories to create release backlogs. Then share the requirements between the teams. How can you quickly and simply create different backlogs and a project plan with the releases and sprints of individual Scrum teams? How does the development team know which requirements depend on each other or which ones are in which editing state? How can you recognize the current status of the team to make prognoses based on it? And what happens if you want to allocate more teams to your project? Use a tool that keeps an overview, even when you have a large number of requirements, and makes your states and dependencies transparent, that supplies you with key performance indicators like the earned value analysis of the team sprint and lets you add new Scrum teams to projects in just a few steps.