The many approaches to scale Scrum — an introduction

Scrum is a framework to address complex adaptive problems. The single source of truth for Scrum is the Scrum Guide. This Scrum Guide is very clear about what Scrum is in a single team environment. It is less clear about multiple teams on the same product.


Sure, the Scrum Guide has something to say about this:

“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.” — Scrum Guide 2017

Knowing that a Product Backlog has one Product Owner it does establish that a Product Owner can work with multiple teams.

Another quote is this one:

“If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done”.” — Scrum Guide 2017

But that is basically it.

But what do you do when you have 3 to 5 teams working from the same Product Backlog. Or perhaps even more teams? There are many challenges that need to be resolved when working with multiple teams from the same backlog:

  • How to manage dependencies?
  • How to prioritise integration issues?
  • How do you coordinate many teams while you still want to remain “Agile” and be able to respond to change and to improve?
  • How can the Product Owner be effective without being in Scrum events 100% of the time?

This is why you see so many scaling variants.

With “Scaling Scrum” we will discuss the scaling variants. We will present each alternative in a separate article and and then assess the pros and the cons and how they can work within a Scrum environment.


You will find links to all published (and pending) articles on the following post containing introduction of LeSS, SAFe, Spotify Engineering culture, Scrum of Scrums, Nexus or assessment of Spotify Engineering Culture, LeSS, SAFe, Nexus, Scrum of Scrums, Scrum@Scale….