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?
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.
What is the Scrum of Scrums?
And how are the other Scrum meetings carried out?
Daily Scrums take place in each team.
Sprint reviews should be carried out with all member of each team.
For organizational reasons, this can take place on multiple levels.
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?
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.
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.
The challenges of working with multiple Scrum teams
Which challenges are there to overcome when working with multiple Scrum teams?
(A quick ad break)