A utilities outage-map product has drifted into three team mini-backlogs with conflicting orders for the same citizen-facing map. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Three mini-backlogs for one outage map is three grocery lists for one kitchen. Pretty soon there are two kinds of milk and no bread. Pull the order back onto one Product Backlog so everyone sees the same next bite.
Full Explanation
Team-level plans may exist as part of Sprint Backlogs, but product order belongs on one Product Backlog. When a utilities outage-map product drifts into three team mini-backlogs with conflicting orders for the same citizen-facing map, the Product Owner should recentralize ordering on one Product Backlog so the product has a single transparent order. Divergent mini-backlogs destroy transparency and create conflicting priorities residents will feel as a incoherent map.
Letting each mini-backlog stand and reconciling conflicts in a monthly steering vote delays coherence and politicizes order. Appointing a lead Developer to own each mini-backlog's order independently misplaces Product Owner accountability. Converting the mini-backlogs into three products so the conflict disappears on paper creates a fake split of one citizen journey.
Outage maps guide safety decisions; conflicting mini-backlogs create conflicting map truths for the same citizens.
Exam caveat: PSPO II insists on one Product Backlog per product; mini-backlogs with conflicting orders are a scaling smell.
Operational check: merge the three mini-backlogs into one outage-map Product Backlog today, publish the single order, and keep Sprint Backlogs as team plans pulled from that order.