skip to content

Mid-Sprint the Sprint Goal becomes unachievable. What does Scrum expect, and who may cancel the Sprint?

level: seniorimportance: should knowfreq 63%

answer

  1. Two different situations hide behind one sentence
  2. The end date never moves
  3. Renegotiate the scope, not the calendar
  4. Obsolete goal, not merely a hard one
  5. One accountability holds the cancellation authority

basics

~20 s

Renegotiate scope with the Product Owner and keep the Sprint's dates, because Scrum never extends a Sprint. If the Sprint Goal has become obsolete rather than merely difficult, the Sprint may be cancelled, and only the Product Owner holds that authority.

solid answer

~50 s

Separate two cases. If the Sprint Goal is still worth pursuing but the selected work will not all fit, the Developers renegotiate scope with the **Product Owner** as soon as they know - dropping or shrinking selected items so the goal is still met - and the Sprint keeps its original end date. Scrum fixes the Sprint length, and extending it to absorb unfinished work destroys the cadence every forecast depends on; unfinished items simply return to the **Product Backlog** to be re-ordered. If the goal itself has become obsolete - the requirement was withdrawn, the market moved, the assumption behind it was wrong - the Sprint may be cancelled, and **only the Product Owner** may do that. The authority sits there because cancelling is a judgement about product value, and the Product Owner holds the single accountability for value.

go deeper

for a junior

Recall that a Sprint has a fixed length and is never extended to fit unfinished work, and that unfinished items return to the Product Backlog. Know that only the Product Owner may cancel a Sprint.

for a middle

Explain the two situations separately: scope renegotiated with the Product Owner while the goal is still valuable, cancellation only when the goal itself is obsolete. Be ready to say why the dates stay fixed.

for a senior

Show the judgement - when you raised the shortfall, what you cut, what you protected, and how you kept the Sprint Goal reachable. An interviewer wants the timing of that conversation as much as its content.

for a principal

Own the pattern above the incident. Repeated cancellations or chronic over-commitment point at Sprint length, at how goals are set, or at dependency structure. Be ready to say which lever you would pull and what pulling it would cost.

## Tell the two situations apart first The sentence *the Sprint Goal is not going to be met* hides two very different problems, and the whole answer turns on separating them. - **The goal is still valuable, but the selected scope will not fit.** This is the common case and it has nothing to do with cancellation. The Developers renegotiate scope with the Product Owner as soon as they know, dropping or shrinking selected items so that the goal itself is still reachable. - **The goal itself has become obsolete.** The requirement was withdrawn, the assumption behind it turned out to be wrong, or the outside world moved. There is nothing worth pursuing for the rest of the Sprint, and cancellation is on the table. Conflating the two is the most common wrong answer. Cancelling a Sprint because the team took on too much is an over-reaction that costs a Planning event and a fresh start; quietly working past the end date because the goal still matters is a different failure with a longer tail. ## The dates do not move Scrum fixes the Sprint's length. Extending a Sprint to absorb unfinished work is not a variant of the framework - it removes the thing the framework is built on. Three consequences follow: 1. Every comparison the team makes between Sprints becomes meaningless, because the periods being compared are no longer the same length. 2. All four inspection points slide with the boundary, so the feedback the team was buying arrives later than planned and the delay compounds. 3. The behaviour is self-perpetuating. A Sprint extended once teaches everyone that the end date is negotiable, and the next shortfall will be met the same way. Unfinished items are not lost. They return to the **Product Backlog** for the Product Owner to re-order, where they compete with everything else on merit rather than rolling automatically into the next Sprint because they happen to be half-built. ## Who may cancel, and why the authority sits there Only the **Product Owner** may cancel a Sprint. The authority sits with the single accountability for the product's value because cancelling is a value judgement: it asserts that the Sprint Goal is no longer worth the days remaining. If the Scrum Master could cancel, a process accountability would be making a product decision. If the Developers could cancel by agreement, a Sprint could end because it had become uncomfortable rather than because it had become pointless. | | Goal at risk | Goal obsolete | | --- | --- | --- | | Cause | The scope was larger than believed | The reason for the goal disappeared | | Response | Renegotiate scope with the Product Owner | Consider cancelling the Sprint | | Who decides | Developers and Product Owner together | The Product Owner alone | | End date | Unchanged | Sprint ends early, a new one starts after Planning | | Expected frequency | Routine | Rare | Cancellation is expensive and should be rare. A team that cancels often has a problem upstream of the Sprint: goals are being set on assumptions that do not survive a fortnight, or the Sprint is longer than the interval at which the business changes its mind. ## A worked example A team maintains a fishing-quota reporting system spread across a 23-service estate, and half its members joined in the past two months. The Sprint Goal for a 9-day Sprint is that vessel operators can file a landing declaration through the new catch-certificate flow. - **Day 3.** The newly-hired half discovers that 7 of the 23 services read the old declaration record directly, so the change is far larger than Planning assumed. The goal is still valuable, so the Developers go to the Product Owner that morning and propose narrowing it: filing for one vessel class only, with the rest left for a later Sprint. The dates do not move, and the trimmed items go back to the Product Backlog. - **Day 6 of a different Sprint.** The regulator withdraws the catch-certificate scheme entirely, pending consultation. Nothing the team could finish in the remaining three days has any value at all. The Product Owner cancels the Sprint. Work already finished and usable is kept; everything else returns to the Product Backlog, and a new Sprint starts with its own Planning. From the inside the two days feel similar - the goal is not going to be met either way - and the correct responses are opposites. Being able to state the test that separates them is most of what the interviewer is listening for. ## What a strong answer includes - Raising the shortfall on the day it becomes known, not at the Sprint Review. - Renegotiating the scope rather than the calendar. - Naming the Product Owner as the only person who may cancel, and saying why the authority sits there. - Treating unfinished work as Product Backlog material to be re-ordered, not as a debt that rolls forward untouched. - Recognising that adding people mid-Sprint rarely makes a goal reachable and usually costs the Developers who have to onboard them.

  • Why does the cancellation authority sit with the Product Owner rather than the Scrum Master?
    Because cancelling is a decision about value, not about process. The Sprint Goal commits the Sprint to a particular piece of product value, and when that value evaporates the person accountable for value decides there is nothing left to pursue. A Scrum Master who could cancel would be making a product call; Developers who could cancel by agreement could end a Sprint that had merely become uncomfortable.
  • How often should a Sprint actually be cancelled?
    Rarely. It is a real part of the framework but an expensive one, and with Sprints of a month or less a goal usually outlives its Sprint. If a team cancels often, the diagnosis is upstream: goals are being set on assumptions that do not survive a fortnight, or the Sprint is longer than the interval at which the business changes its mind.
  • What happens to the work already completed when a Sprint is cancelled?
    Finished, usable work is kept and can be delivered; everything else goes back to the Product Backlog for the Product Owner to re-order against the rest. A new Sprint then starts with its own Sprint Planning. Cancelling ends the pursuit of a goal that no longer has value - it does not discard the work already done.
  • The Developers realise on day two that they took on far too much. When do they say so?
    Immediately. Scope is renegotiated with the Product Owner as more is learned, and the value of that conversation decays every day it is postponed: a cut made on day two leaves the goal reachable, while the same cut on the final day is just an apology. Waiting until the Sprint Review to reveal the shortfall is the failure, not the shortfall itself.

A Sprint is a scheduled flight rather than a delivery van: you can leave cargo behind to make the weight, but you cannot ask the airport to move the landing slot.

saying these in an interview costs you the question

  • Extends the Sprint by a few days to finish the work
  • Says the Scrum Master decides whether to cancel a Sprint
  • Waits until the Sprint Review to reveal the shortfall
  • Cancels the Sprint whenever the selected scope will not fit
  • Assumes unfinished items automatically roll into the next Sprint
  • Adds people mid-Sprint expecting the goal to become reachable