One Scrum Team's list now contains parks-booking items, clinic-portal items, and permit-search items as if they were a single product. No one can say which Product Goal the order serves. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Three restaurants sharing one ticket rail is how the wrong plate leaves the kitchen. Parks, clinic, and permits are not one product just because one team is hungry. Draw the product lines—and if they still share people, say out loud how that capacity is being chosen.
Full Explanation
A Product Backlog belongs to a product with a Product Goal. When one Scrum Team’s list silently contains parks-booking, clinic-portal, and permit-search items as if they were one product and no one can say which Product Goal the order serves, the Product Owner must clarify product boundaries and, if capacity is shared, make portfolio-level ordering explicit rather than merging unrelated products. Keeping one opaque combined list so the team never declines a department hides accountability and makes order uninterpretable for civic stakeholders. Appointing three Product Owners on the same unordered mash-up without defining products multiplies confusion without creating focus. Renaming the list a program backlog and stopping ordering avoids a real product-boundary decision. Exam caveat: multiple products may share one team’s capacity, but that shared capacity must be an explicit portfolio choice—not a nameless dump of unrelated municipal services. Operational check: identify separate Product Goals and backlogs per true product, expose how capacity is allocated across parks, clinic, and permits, stop silent cross-product dumping, and inspect that each civic product’s order is explainable to its stakeholders.