A county public-health clinic portal is behind on a flu-shot booking Increment. The health director wants to cancel this Sprint Review so Developers get two more hours of coding. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Skipping the Review to save time is like never tasting the soup so the cook can stir faster. That event is the regular chance to see whether clinic staff and residents can actually book shots. Empiricism on the product dies the moment inspection is postponed.
Full Explanation
The Sprint Review is the formal opportunity to inspect the Increment and adapt the Product Backlog with stakeholders. When a county public-health clinic portal is behind and the health director wants to cancel Review so Developers get two more hours of coding, the Product Owner should keep the Review so stakeholders can inspect the Increment and adapt from real evidence. Empiricism on flu-shot booking dies when inspection is postponed for output.
Agreeing to skip the Review this Sprint and add two hours to a longer coding block trades transparency and adaptation for marginal coding time. Replacing the Review with a written status deck the director can read after hours removes interaction with a usable Increment. Moving inspection to a quarterly public-health steering committee so Sprints stay protected stretches the feedback loop beyond decision usefulness.
Exam caveat: PSPO II protects Sprint Review against cancel-for-coding pressure; status decks and quarterly steering are not substitutes.
Operational check: hold the clinic Sprint Review on schedule, inspect whatever is Done, adapt the Product Backlog for booking value, and schedule extra coding only inside future Sprint forecasts—not by deleting inspection.