Three Scrum Teams now work on one city building-permit product. Department heads want a Product Owner and a backlog per team. What should the Product Owner maintain?
Select an answer to reveal the explanation.
Short Explanation
One product, one menu, one person accountable for the order. Three permit backlogs is three restaurants pretending they share a kitchen. Residents file one permit, so the city needs one Product Backlog and one Product Owner.
Full Explanation
Scrum scales around the product, not around team count. When three Scrum Teams work on one city building-permit product and department heads want a Product Owner and a backlog per team, the Product Owner should maintain one Product Owner accountability and one Product Backlog for the single permitting product. Residents file one permit, so the city needs one coherent order and one Product Goal—not three competing menus.
Three Product Owners who vote weekly on a merged order diffuse accountability into a committee. One Product Owner per permit type with independent backlogs that integrate at year-end hides conflict until a late big bang. A PMO-owned master schedule that replaces the Product Backlog for the three teams is not a Product Backlog and severs empiricism from the Product Owner.
One permitting journey for residents means one Product Backlog and one Product Owner, regardless of how many teams pull work.
Exam caveat: PSPO II multi-team scaling keeps one Product Owner and one Product Backlog per product.
Operational check: collapse team wish lists into one permits Product Backlog ordered by one Product Owner, share one Product Goal, and let teams pull from that single order.