Chapter 9. Know the Difference Between Multiple Scrum Teams and Multi-Team Scrum
Markus Gaertner
When applying Scrum to a product with more than one Development Team, there is little guidance in the Scrum Guide, which for the most part seems focused on one-team Scrum. The only hint you get is in the Product Backlog section:
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.
We learn that, with multiple teams, we are advised to still use a single Product Backlog. Nothing is mentioned regarding the roles of Product Owner, Development Team, or Scrum Master other than “multiple Scrum Teams” working on the same product.
But how do you decide on priorities? If we take the Scrum Guide literally, there could be more than one Product Owner in each Scrum Team working on that product, or it could be the same person for all the teams involved.
Generally, this is the distinction between “Multiple Scrum Teams” and “Multi-Team Scrum.”
Multiple Scrum Teams
“Multiple Scrum Teams” typically holds that each Development Team has a Product Owner, although there is a single Product Backlog. That means that, potentially, different people in the role of Product Owner need to coordinate with one another regarding their individual priorities and come up with the most valuable items to be worked on for the product.
Sometimes this setup seems connected to having different specializations in the Development Teams, where different teams work only in specific functional product areas. This works well if the workload on each of the specialist topics is evenly distributed across the different teams—and will stay that way for the near future. If that is not the case (which is highly likely), then one team might end up working on lower-priority, and therefore lower-value, work for the product, just because that type of work is their specialty.
This setup generally also reduces the transparency and insights into the whole product. Not only is the in-depth knowledge about the product split across the different Scrum Teams, but also across the different Product Owners. After development on particular features has finished, additional coordination is needed on the different partial results of the product in order to integrate them into a whole product that can be released to the customer and user. Unfortunately, a “Multiple Scrum Teams” setting provides little incentive for cross-team collaboration, since everything will be taken care of by the additional coordination overhead the setup produces.
Multi-Team Scrum
In a “Multi-Team Scrum” setting, there is not just a single Product Backlog, but also a single Product Owner who works with the multiple Development Teams. The sole Product Owner makes product-wide decisions that are fully transparent via the single Product Backlog and the product versions created.
This setting demands a cross-functional approach from the teams. Specialization in the customer domain may still exist but will have to dissolve once priorities and demands start to shift. For example, one team working on accounting functionality will have to shift from accounting features to another type of feature if there are no longer any accounting features as the highest priority in the Product Backlog.
This setting, therefore, lays the demand for coordination with the teams themselves. They have to make sure they deliver an integrated product Increment at the end of every Sprint.
Depending on where you start, this may result in a steep learning curve. It is worth it.