A public-health clinic scheduler has a Done Increment that already cuts no-show rates, two months before the city's published calendar go-live. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Sitting on a clinic Increment that already cuts no-shows is like leaving flu shots in the fridge because the poster still says 'shot day' is two months out. Calendar trains are optional coordination, not a Scrum lock. When it is Done and valuable, ship it and re-forecast what comes next.
Full Explanation
A Done Increment of a public-health clinic scheduler that already cuts no-show rates creates Current Value two months before a published calendar go-live; the Product Owner should release it now and update the forecast rather than waiting on the train. Holding the Increment until the published go-live so every department stays synchronized optimizes calendar politics over resident health access. Filling unused calendar time with extra features so the original date still looks fully loaded invents scope to justify delay. Asking the mayor's office to re-baseline and delay any release until the next quarterly window further postpones proven value. Exam caveat: early release of valuable Done Increments is encouraged; artificial train gates are not a substitute for Product Owner judgment on PSPO II. Operational check: verify Done and operational readiness, release the no-show-reducing Increment, measure outcomes, and revise any remaining calendar promises to reflect what has already shipped to clinics and residents. Early release of a Done clinic scheduler Increment that already reduces no-shows is Product Ownership maximizing Current Value, not schedule disobedience. Measure the outcome after release and revise remaining calendar promises so the city does not pretend the value is still pending.