The Scrum Team should consist of up to ten people. But what to do when a larger group of specialists needs to work on one project? Or if the organization decides to follow an agile way of management? To solve this problem, Scrum developers proposed Scrum@Scale. It is a scale-free architecture to organize whole teams according to Scrum principles.

Scaling Scrum – table of contents:

  1. Introduction
  2. Scrum@Scale
  3. The Scrum of Scrums
  4. Further scaling and Scrum@Scale issues
  5. Summary


As soon as an organization grows, new kinds of problems appear. For instance, a drop in employee effectiveness that’s caused by complex internal structure, difficult decision-making or direction setting. Companies operating agile at the small project-team level often look to scale up.

Many enterprises do well without scaling Scrum. Even if many Scrum Teams are running simultaneously, they don’t need coordination as the groups operate independently. However, this does not mean that it is a multi-team Scrum. The need for scaling comes only when most of the organization is working on one product and can synchronize its multiple Scrum Teams effectively.

Most organizations that adopt agile management methods at scale choose the SAFE model, or Scaled Agile Framework. Today, however, we won’t focus on SAFE but we’ll discuss a different model called Scrum@Scale, as according to the 15th State of Agile report from 2021, it’s the second-best choice among businesses that opt for agile.


In 1996, the creators of Scrum, Jeff Sutherland and Ken Schwaber, were working on a large project. As they were doing it, they were having trouble keeping smaller teams working in Scrum in sync. They came up with a way to scale it, which they eventually called Scrum@Scale.

Analogous to the official Scrum Guide was the Scrum@Scale Guide, which defines this way of scaling work as:

A framework within which networks of Scrum Teams operate following the Scrum Guide to solve complex adaptive problems and creatively deliver products with as much value as possible.

The basic premise of Scrum@Scale is simplicity and efficiency. Therefore, its operation is based on a scale-free architecture. In other words, it uses Scrum to scale Scrum. In such a way, a scrum team composed of individuals acting as Product Owner, Scrum Master or Developer becomes the Scrum of Scrums: a team consisting of teams.

The Scrum of Scrums

The Scrum of Scrums is a scrum team with people taking traditional Scrum roles. However, since the task of Scrum of Scrums is to integrate the results of the work of several Scrum Teams, it needs additional posts:

  • Product Owner Team – a group of Product Owners who meet to agree on priorities and create a cohesive product vision
  • Chief Product Owner – Scrum Team’s Product Owner or a person who deals exclusively with the Scrum of Scrums
  • Scrum of Scrums Master – the person who oversees the effectiveness of the Scrum of Scrums.

They meet at the same Scrum Events and use similar Artifacts.

Scaling Scrum

Further scaling and Scrum@Scale issues

The scale-free architecture of Scrum@Scale means that it enables scaling more than just once. If an organization needs to coordinate teams on an even larger scale, it can set up Scrum of Scrums.

However, scaling Scrum, like any other management methodology has its flaws, and in this case, they are similar to those of the basic Scrum Teams, only they are proportionally greater. That’s why we recommend to work out the details of the collaboration within each Scrum Team before starting Scrum on a larger scale. We suggest scaling Scrum for experienced teams that have a good knowledge and understanding of values and workings of Scrum.

scaling scrum

Scaling Scrum – summary

Scaling Scrum is no child’s play. It requires Scrum Teams to proficiently apply Scrum principles and synchronize their tasks with other Scrum Teams. Therefore, the basic question to answer is: Is scaling needed? Just because there are many Scrum Teams in an organization doesn’t automatically mean that coordinating them will bring better results.

If an organization chooses to augment Scrum, it gains a scale-free architecture that can be successfully augmented further. However, each augmentation is accompanied by an increase in the level of complexity that the Product Owner Team, Chief Product Owner, and Scrum of Scrums Master must deal with.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 16. Scaling Scrum caroline becker avatar 1background

Author: Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing