A home-robot company's Product Owner cancels a Sprint after a critical safety recall makes the Sprint Goal irrelevant. Several Product Backlog items were already finished and meet the Definition of Done when the cancellation happens. What happens to that work and to the unfinished items?
Select an answer to reveal the explanation.
Short Explanation
Cancelling a Sprint doesn't erase the work that already happened — it just stops the plan the Sprint was chasing. Anything that already met the bar for 'done' stays done, and anything still in progress just goes back into the pool to be picked up again later. Nothing gets thrown away just because the container closed early.
Full Explanation
When a Sprint is cancelled, completed and 'Done' Product Backlog items are reviewed — if part of the work is potentially releasable, the Product Owner typically accepts it, since Done work does not simply vanish because the Sprint itself ended early. Incomplete items are put back on the Product Backlog for future consideration, since they haven't disappeared either; they're simply no longer part of an active Sprint Backlog. Discarding all Sprint work misunderstands what cancellation actually undoes — it ends the current Sprint container and its now-obsolete goal, not the value already produced inside it. A Developer vote on which finished items to keep has no basis in the Guide; accepting completed work sits with reviewing it against the Definition of Done and the Product Owner's judgment about releasability, not a team vote. Forcing the next Sprint to repeat the identical Sprint Goal ignores why the cancellation happened in the first place — the goal was rendered obsolete, so the next Sprint Planning starts fresh from the current state of the Product Backlog and Product Goal, informed by the recall but not bound to replay the same plan. A concrete check: after any Sprint cancellation, confirm the Product Backlog was actually updated to reflect what returned to it, rather than silently dropped from tracking.