Scrum of Scrums

What is Scrum of Scrums, what are the differences to the Daily Scrum, who are the participants, what are the advantages and tips?

Scrum of Scrums Definition

The Scrum of Scrums refers to a regular meeting of representatives of individual Scrum teams. It serves the purpose of exchanging information on the status quo of the individual teams, on upcoming activities and possible obstacles to development. The aim of the Scrum of Scrums is to synchronise the work of the different Scrum teams and to identify developments of teams that influence other teams in the implementation of their requirements. It is therefore a technique for scaling Scrum and relevant for many larger companies.

Ideally, each team sends a representative to the Scrum of Scrums meeting so that all teams are equally represented. The work of the Scrum of Scrums meetings can also be continued at a higher level – with representatives from the various Scrum of Scrums rounds. Although formulations such as Scrum of Scrum of Scrums are easy to understand, they have not been accepted by the Scrum community.

Differences between Daily Scrum and Scrum of Scrums

Daily Scrum and Scrum of Scrums are very similar. At the Daily Scrum each team member is allowed to answer three questions:

  • What have I been doing since yesterday to reach the sprint goal?
  • What will I do until tomorrow to reach the sprint goal?
  • What is it that hampers my work?

Since every participant in the Scrum of Scrums acts as a team ambassador, the questions are reformulated:

  • What has my team accomplished since we last meeting?
  • What will my team do before the next meeting?
  • What are the obstacles my team faces at work?
  • Could one of my team’s activities affect or hinder another team?

The answer to the last question is particularly important, because it is imperative that the findings are passed on from the representatives to their own teams.

Scrum of Scrums - a meeting with representatives of individual Scrum teams

Frequency and Timebox for Scrum of Scrums

Opinions about the frequencies of a Scrum of Scrums vary. A daily meeting is often recommended, but other rhythms such as once or twice a week may be sufficient. It is important that you do not arrange a new date with the participants every time, but that you make appointments in advance. For example, the representatives could meet every Tuesday and Thursday and a Scrum of Scrum of Scrums could take place every Friday.

It is recommended to work with a timebox at the Scrum of Scrums. The duration should be determined by the representatives together and depending on the number of participants. Some organisations deliberately choose not to have a daily meeting of 15 minutes, but to have longer meetings of 45 or 60 minutes. This makes particular sense if problems that affect all teams and thus all employees are to be discussed in the meetings and, if possible, solved directly.

Scrum of Scrums in practice

Participants at the Scrum of Scrums

Whoever meets in a Scrum of Scrums meeting is not standardised. In some organisations the product owners always meet, in others the Scrum Masters. Frequently, experts who are involved in the concrete implementation of requirements, e.g. a software architect, a developer or a tester, are also delegated.

A change of team ambassadors is also conceivable, so that a UX expert could attend the meetings more often at the beginning of the project, since many design decisions have to be made in this early project phase. In the course of the project, a tester could then be sent to the meetings more frequently. In principle, no more than nine participants should participate in the meetings – this leads, for example, to several Scrum of Scrums if there are 10 or more participants.

Dependencies between teams

If different teams – possibly even at different locations – are working on the development of a joint solution, dependencies between the teams should ideally be reduced. For this we recommend

  • to fill each team cross-functionally, so that the tasks set in the team can be solved as independently as possible.
    To describe user stories according to the INVEST principle, so that each story can be realised independently of other stories.
  • to cut user stories in such a way that all layers of the architecture are taken into account, so that implemented functions can also be potentially available. Here, user story mapping is a good method.
  • to use an user story mapping as method to consistently maintain the product backlog so that the distribution of backlog items to the individual teams can take place quickly and in a structured manner.
  • to synchronise the sprint lengths and sprint dates so that teams do not have to wait unnecessarily for each other or the integration of solution parts is not delayed.

 

Advantages of Scrum of Scrums

The scaling of Scrum offers a number of advantages:

  • Regular communication and collaboration between the different teams is encouraged.
  • Each team knows the status quo of its own development, knows which tasks are pending and which obstacles have to be removed.
  • The progress of the project becomes visible for all participants.
  • Dependencies between teams are reduced.
  • Risks are reduced by teams taking care not to hinder other teams with their developments.
  • Problems are clearly addressed and solutions are sought together. Concrete support across team boundaries to solve concrete challenges is also conceivable.
  • At the end of the sprint, each Scrum team delivers a part of the product increment. The system to be developed thus grows incrementally through the results of the individual teams. Coordination takes place via the Scrum of Scrums.

 

Want to know more about Scrum?

Then learn more about the Sprint Planning procedure, tips and tricks for the Sprint Review or the different methods of a Retrospective.

Challenges for companies

Tips and tricks for Scrum of Scrums

Organisations working with multiple teams face a number of challenges. Here are some recommendations for the implementation of Scrum of Scrums:

  • Team representatives should not name team members, because they represent their entire team, not individual colleagues. In addition, descriptions and later problem discussions remain at a technical level as far as possible.
  • Keep it short and sweet, i.e. each participant should stick to his or her time limit, especially as the importance of topics is not influenced by the length of the speech.
  • In contrast to the Daily Scrum, problems can also be addressed in the meetings. However, solutions should only be discussed after each team ambassador has answered his or her questions.
  • If the teams work at different locations, the Scrum of Scrums meeting usually cannot be held at the same location. Digital tools such as video conferencing can help.
  • If it is necessary to document results and findings, organisations must discover ways to generate these documents quickly and easily, version them if necessary and then make them available to the team ambassadors or the individual teams. In order for such documentation to be as useful as possible, it must be available again as a working tool at the next meeting.
  • The appropriate frequency must be defined – on the one hand, companies want regular exchange, on the other hand, the implementation of meetings causes expenses. It is therefore important to make the Scrum of Scrums as short and meaningful as possible, and at the same time to address aspects relevant to the teams, such as problems and possible problem solutions.
  • The implementation can also be optimised and enhanced. Companies should therefore obtain feedback from the representatives involved – but of course not during a Scrum of Scrums meeting and probably not with a timebox.
  • If there is a Scrum of Scrum, there can also be a Retrospective of Retrospectives. These meetings should also be scheduled accordingly, with representatives of the individual teams, etc.

 

We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the collection, structuring and administration of requirements and pay attention to consistency, completeness and traceability. We support you in identifying technical correlations and consider stakeholders, goals and boundary conditions. And we plan and control your projects with these requirements on the basis of defined processes.

Find out more about software development here  »

More details and information ...