As the home-robot product grows, the company splits into an app Scrum Team and a firmware Scrum Team, and the two teams start keeping separate backlogs of work they each think is most important, causing conflicting priorities. What does the 2020 Scrum Guide say should happen instead?
Select an answer to reveal the explanation.
Short Explanation
One product, one backlog — that's the rule even when several teams are pulling from it. Think of the Product Backlog like a single shared shopping list for the whole household: everyone can grab items off it, but there's only one list and one Product Owner keeping it ordered.
Full Explanation
The 2020 Scrum Guide is explicit that when multiple Scrum Teams work on one product, there is still a single Product Backlog, a single Product Goal, and one Product Owner accountable for ordering it — that shared structure is exactly what prevents the conflicting-priorities problem described here. Giving each team its own Product Backlog and Product Owner treats them as two separate products rather than one, which is precisely the fragmentation that caused the conflict in the first place. Having the two Scrum Masters jointly set priorities misassigns accountability — the Scrum Master serves the Scrum Team and organization, but managing the Product Backlog and maximizing value belongs to the Product Owner, not to Scrum Masters acting as a steering committee. Merging into one giant team ignores that Scrum Teams stay small enough to remain nimble; the Guide's answer to scale is more Scrum Teams sharing artifacts, not one oversized team. A practical check: verify both teams can point to the same Product Backlog and the same Product Goal statement — if they can each only name their own, the structural fix hasn't actually landed yet.