Sprint Cancellation and the Sprint Goal
TransitPay runs four-week Sprints. In Sprint 4 of 6, the Sprint Goal is 'Customers can pay with a saved card.' With six days left, about 60% of the Sprint Goal is complete: the payment token service is integrated and one checkout path works, but the saved-card management screen is not started. The Product Owner learns a competitor has launched cryptocurrency payments and wants to cancel the Sprint immediately to start crypto work. The engineering manager tells the team to 'finish saved cards but also start crypto in parallel' and to skip the Sprint Retrospective to save time. Two Developers are on leave next week. The Product Backlog has a refined crypto epic, but it is estimated at three Sprints and depends on a vendor contract not yet signed. The team has four Developers plus a Product Owner and Scrum Master; the Scrum Master is unsure whether cancellation is allowed mid-Sprint.
1. Can the Product Owner cancel the Sprint? Under what condition, and what happens to the work already done?
Read the worked answer
Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete. A new competitor feature, a manager's request, or a tempting new epic is not by itself sufficient; the PO must judge that the Sprint Goal no longer makes sense. Cancellation is rare and should be treated as a serious event because it consumes team capacity and disrupts learning.
When a Sprint is cancelled, the Sprint ends immediately. Any completed and accepted Product Backlog items are reviewed; if they meet the Definition of Done and are potentially releasable, the PO may accept them. Incomplete items return to the Product Backlog, are re-estimated, and are reordered. The team then holds a Sprint Retrospective to inspect why the cancellation happened, and a new Sprint Planning follows. The Scrum Master should ensure the mechanics are followed and that the team does not simply continue working on cancelled scope. The engineering manager cannot cancel the Sprint, and the team cannot cancel it unilaterally.
2. Should the Product Owner cancel this Sprint? Analyze the trade-offs using the scenario.
Read the worked answer
On the facts, cancellation is hard to justify. The Sprint Goal - saved-card payments - is not obsolete: 60% is complete, one checkout path works, and the capability still has customer value. The crypto opportunity is real but not actionable at Sprint speed: the epic is estimated at three Sprints and depends on an unsigned vendor contract. Cancelling now would discard six days of remaining work and still not let the team start crypto immediately; it would create churn and reduce trust.
The better economic choice is to finish the Sprint Goal, then let the Product Owner reorder the Product Backlog with the new market information. The PO should also refine the crypto epic and resolve the contract dependency, because those are the real constraints. If the PO believes the goal is genuinely obsolete, the Scrum Guide allows cancellation, but the decision must be based on the value of the goal, not on fear of a competitor. The Sprint Goal exists to protect focus and prevent exactly this kind of mid-Sprint disruption.
3. If the Sprint is not cancelled, how should the Scrum Team respond to the engineering manager's request and the new market information?
Read the worked answer
The Scrum Team should not follow the manager's instruction to run two efforts in parallel. The Product Owner owns product ordering; the Developers own how to achieve the Sprint Goal. The correct response is: the PO assesses the new information, the Developers protect the Sprint Goal, and the manager is coached that assigning work to the team undermines self-management.
Practical steps: the PO adds the crypto opportunity to the Product Backlog and orders it against saved-card work; the team raises the conflict at the Daily Scrum and, if needed, the PO negotiates scope with the Developers without changing the Sprint Goal. The Retrospective must not be skipped - it is where the team inspects the disruption and decides how to handle future mid-Sprint requests. If the PO concludes the Sprint Goal is obsolete, cancellation is the legitimate path, with the work returned to the backlog. Otherwise, the team finishes the current goal, and the PO brings the market news to the Sprint Review so stakeholders can see the trade-off. The Scrum Master's job is to make that process explicit, not to act as a messenger for the manager.