As the home-robot company grows from one Scrum Team to four — app, firmware, cloud, and hardware — the firmware team's lead proposes each team keep its own separate Product Backlog so they can move independently. What does the Scrum Guide say about this, given there is one product?
Select an answer to reveal the explanation.
Short Explanation
One product, one plan — even with four teams pulling from it, there's still just one Product Backlog and one Product Owner accountable for it. Splitting it up team-by-team turns coordinated priority into four separate guesses.
Full Explanation
When multiple Scrum Teams work on one product, the Scrum Guide's expectation is that Product Backlog management still resolves to a single Product Backlog and a single Product Owner accountable for its content, availability, and ordering — the Product Owner may enlist help, but accountability doesn't split by team. Letting the firmware team split off its own backlog because its cadence differs — PCB spins and certification cycles genuinely don't move at software speed — sounds practical but breaks the single source of priority: the app team could then be building against a Wi-Fi feature the hardware team has quietly deprioritized, with no shared view of that tradeoff. Giving each team its own Product Owner has the same failure mode from a different angle: it creates four independent value judgments instead of one, and the whole point of scaling from a single Product Owner is that someone still holds the full picture of what matters most for the one product. The Guide does allow structures to support this at scale, but the underlying single-backlog, single-accountable-Product-Owner shape holds. A useful check: if you ask any of the four teams what the top item in the product's backlog is, do they name the same item?