Top vaccine-booking items on a health-department Product Backlog are too vague for Developers to forecast a Sprint. A program office responds by demanding a 40-page specification covering the whole season before any further Sprint. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
The next at-bat needs a scouting report—not a novel about the entire season. Get the top items clear enough to forecast a Sprint, and let later items stay sketchy until they move up. Waterfall specs for everything just in case is how civic teams stall out.
Full Explanation
Product Backlog refinement makes upcoming items ready enough for Developers to forecast a Sprint; it does not require complete specifications for distant work. When top vaccine-booking items on a health-department Product Backlog are too vague to forecast and a program office demands a forty-page specification for the whole season, the Product Owner should refine near-term items just enough for a Sprint forecast without waterfall detail for the entire campaign. Halting Sprint Planning until every future campaign is fully specified reintroduces delay and false certainty. Leaving the top items vague and letting Developers invent scope during the Daily Scrum makes Planning fail and hides intent. Replacing refinement with a change-control board that signs pixel mockups substitutes output compliance for collaborative readiness. Exam caveat: ready-enough is contextual—riskier health workflows may need sharper acceptance criteria—but readiness still focuses on near-term forecast, not whole-product specification. Operational check: schedule ongoing refinement with Developers, clarify the top few booking items’ intent and acceptance, confirm a Sprint Goal is forecastable, keep later season items coarser, and refuse the forty-page gate as a precondition for the next civic Increment.