A home-robot company is scaling from one Scrum Team to three as it adds a cloud-services product line, and all three teams pull items from the same overall product. According to the 2020 Scrum Guide, what is the minimum structural requirement across these three Scrum Teams regarding the Product Backlog?
Select an answer to reveal the explanation.
Short Explanation
Multiple teams building one product still need to be reading from the same page. The Guide's answer to scaling isn't three separate to-do lists — it's one shared Product Backlog that every team pulls from, so nobody's optimizing their own slice at the expense of the whole product.
Full Explanation
The 2020 Scrum Guide addresses scaling by stating that when multiple Scrum Teams work together on one product, they share one Product Backlog, using techniques like domain or Product Goal grouping to organize the work across teams rather than each team inventing its own separate list. This keeps ordering and value trade-offs coherent across firmware, app, and cloud work instead of fragmenting into competing backlogs that no longer reflect one product's priorities. Giving each team its own fully independent Product Owner misreads the Guide's scaling guidance — while a large product can involve more than one Product Owner or Product Owner support structure, the emphasis is on one shared backlog and coherent product direction, not fully independent authority splintering value decisions per team. Forcing all three teams to merge back into one large team is also wrong and contradicts the very team-size guidance that motivates splitting into multiple teams in the first place. Maintaining separate Product Backlogs per team is the actual anti-pattern the Guide is steering scaling teams away from, since it recreates silos. A concrete check when scaling: can any team member point to the one backlog the whole product pulls from? If there are multiple competing lists, the scaling approach has drifted from the Guide.