When applying Scrum to a product with more than one Development Team, Scrum Guide guidance is almost entirely focused on a single-team Scrum. This is all you have to go on:
Many Scrum Teams often work on the same product. One Product Backlog describes upcoming work on the product. Some Product Backlog attributes might then be used.
In multi-team environments, we are advised to use a single Product Backlog. The Product Owner, Development Team, and Scrum Master are all only referred to as “multiple Scrum Teams”.
How do you determine priorities? If we follow the Scrum Guide literally, there could be more than one Product Owner working on each product, or the same person for all the products.
“Multiple Scrum Teams” versus “Multi-Team Scrum.”
Many Scrum Teams
There are multiple Scrum Teams, each with their own Product Owner, but only one Product Backlog. If two people serve as Product Owner for different projects, then they must coordinate their priorities and identify the most valuable items to work on for the product.
Sometimes, this looks like having specialised Development Teams, where different teams focus on functional product areas only. As long as the workload for each of the specialist topics is distributed evenly across the different teams, this works well. In that case, one team might have to work on lower-priority, and therefore lower-value, work for the product because that is their specialty.
This system lowers the product’s transparency and usefulness. Additionally, the in-depth knowledge about the product is split across Scrum Teams, and even across Product Owners. The coordination required is greatest after the various features have finished development. Unfortunately, “Multiple Scrum Teams” has little effect on inter-team collaboration, since the setup produces too much coordination overhead.
MTS ( Multi Team Scrum)
A “Multi-Team Scrum” uses a single Product Backlog, but multiple Development Teams all report to the same Product Owner. The Product Owner only makes decisions that apply to the entire product and are transparent to the entire team.
Each team must collaborate across functional boundaries. Priorities and demands will begin to shift, causing specialisation in the customer domain to dissolve. For example, one team working on accounting features must switch gears and work on another type of feature if accounting features have been cut from the Product Backlog.
Because of this setting, coordination with the teams is required. Every Sprint, they must make sure they deliver an integrated product Increment.
As you begin, it may result in a steep learning curve. It is worthwhile.
Featured Image Credit | Image Source: GOOGLE SEARCH | Distributed & Large Scrum Projects
