Two city departments each demand their unrelated must-have in the same Sprint for a shared municipal product. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Two must-haves in one Sprint is two parades on the same street. Show both departments what splitting does to the forecast, then sequence for value. A tie so nobody is mad is how both features show up late and half-Done.
Full Explanation
When two city departments each demand an unrelated must-have in the same Sprint for a shared municipal product, split focus lengthens cycle time and weakens release forecasts. The Product Owner should forecast the impact of splitting focus and propose sequencing the work so value and forecast confidence stay intact, because ordering the Product Backlog is a Product Owner accountability. Splitting the Developers in half so both departments get a little of each must-have this Sprint often leaves both paths unfinished and neither Done. Accepting both as Sprint Goals so neither department feels deprioritized produces competing Sprint Goals and muddies inspection of whether the Sprint succeeded. Escalating to the Scrum Master to pick the winner because ordering is supposedly not a Product Owner job abdicates the core Product Owner accountability for value order. Exam caveat: sequencing with transparent forecast impact is how both departments eventually receive Done Increments without destroying empiricism. Operational check: model cycle-time and forecast effects of splitting versus sequencing, present that comparison to both departments, order the higher-value path first, and confirm a single coherent Sprint Goal for the next Sprint.