Sprint Planning for a city building-permit portal starts, and the top of the Product Backlog is still an unrefined pile of department wishes. Developers cannot forecast a coherent Sprint. What accountability did the Product Owner miss?
Select an answer to reveal the explanation.
Short Explanation
Walking into Planning with a junk-drawer backlog is like showing up to cook dinner with unlabeled cans and no idea what the meal is. The Product Owner owes the team a top of the backlog that is ordered and clear enough to chew on. Perfect permit specs are not the job; ready enough is.
Full Explanation
The Product Owner is accountable for the Product Backlog, including ordering and making items transparent enough that Developers can select work and craft a Sprint Goal. Arriving at Sprint Planning for a city building-permit portal with an unrefined pile of department wishes means the Product Owner missed ensuring the most valuable items at the top were clear enough to plan a Sprint toward the Product Goal. Ready enough—not perfect waterfall specs—is the bar.
Writing a complete technical design so Developers would not need to ask questions over-specifies how and still may leave value unclear. Asking the Scrum Master to invent a Sprint Goal before anyone saw the work invents coherence without backlog clarity. Converting every permit type into a fixed specification packet before Planning is allowed recreates analysis paralysis instead of ongoing refinement.
Exam caveat: PSPO II Product Backlog accountability includes refinement readiness for Planning; unrefined tops are a PO miss, not a Developer or SM failure.
Operational check: before the next Planning, refine and order the top permit items with clear outcomes and enough detail to forecast; keep deeper design emergent during the Sprint.