A library digital-card team finished about half the stories hoped for this Sprint, but the Increment validated a risky assumption about cardholders proving identity online. What should the Product Owner do next with the release forecast?
Select an answer to reveal the explanation.
Short Explanation
The identity proof actually working is the gold; the unfinished story count is just leftover groceries. When a risky assumption gets validated, the forecast and the order should move, not sit in the penalty box. Chasing point recovery is how libraries ship the wrong card flow on time.
Full Explanation
When a library digital-card Increment finishes fewer hoped-for stories but validates a risky assumption about cardholders proving identity online, that learning should update the release forecast and Product Backlog order immediately. Empiricism treats validated assumptions as higher-value evidence than unfinished story-point counts; some remaining work may become unnecessary, cheaper, or more urgent because identity proof now works. Keeping the original forecast unchanged and adding a velocity-recovery Sprint to catch up on points protects a stale date instead of adapting to what the Increment taught. Treating unfinished points as debt the Developers must repay before any forecast may change invents an accounting rule that Scrum does not require and delays value-based reordering. Hiding unfinished stories from Sprint Review so the library board still sees the original date intact withholds transparency and turns Review into status theater. Exam caveat: PSPO II expects Product Owners to adapt forecasts from Sprint Review evidence, including when throughput looks lower but risk reduction is real. Operational check: after Review, rewrite the outlook to reflect the validated identity path, reorder or remove backlog items that depended on the old uncertainty, and tell the board what changed and why.