The Sprint Retrospective and cancelling a Sprint

The event that concludes the Sprint

The Sprint Retrospective is the last event of the Sprint — the Sprint Review is second to last — and it is timeboxed to a maximum of three hours for a one-month Sprint. Its purpose is to plan ways to increase quality and effectiveness, and the word plan is doing real work in that sentence: a Retrospective that produced a shared feeling and a list of observations has done half of the event.

A team that runs the full three hours because "that is what Scrum says" and a team that spends forty-five useful minutes are not both following the framework. The figure is a ceiling stated for a one-month Sprint exactly like the other two, Scrum publishes no scaled maximum for a two-week Sprint, and filling a timebox for its own sake is how a team learns to resent the one event that exists to make its life better.

What it inspects, including the entry candidates miss

The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. Four of those five surprise nobody. The fifth is the one worth carrying into the exam room: the Definition of Done is inspected HERE, which is why it is not renegotiated at Sprint Planning and not the subject of the Sprint Review.

Scrum adds a step that separates a useful Retrospective from a round of complaints — the assumptions that led the team astray are identified and where they came from is explored. That is a question about cause rather than symptom. It is also why a two-day wait for a shared test environment is squarely in scope: tooling is named explicitly, and an impediment that has survived six Retrospectives is not a fact of life, it is the thing the event exists to remove.

Improvements that actually happen

A wall holding a dozen improvements that never happen is the standard failure, and Scrum's own remedy is deliberately concrete: identify the most helpful changes, address the most impactful ones as soon as possible, and if it helps, add them to the Sprint Backlog for the next Sprint. Putting an improvement into the Sprint Backlog is what turns it from a wish into work the Developers have planned, can inspect at the Daily Scrum, and have to weigh against everything else they took on.

Every plausible wrong answer moves it somewhere worse. Into the Product Backlog, where the team's own way of working is ordered against customer-facing value and comes permanently last. Onto a named individual as a personal action item chased at the Daily Scrum, which cuts across self-management and repurposes an event that exists to inspect progress toward the Sprint Goal. Or into a Retrospective held every second Sprint, which halves the inspection of a team whose problem is that it adapts nothing.

Cancelling a Sprint

A Sprint may be cancelled if the Sprint Goal becomes obsolete, and only the Product Owner has the authority to do it. Not the Scrum Master, who ensures the events happen but holds no authority over the product. Not the Developers by consensus, who can change everything inside the Sprint without ending it. Not whoever is funding the work, who influences the product the way every other stakeholder does: by convincing the Product Owner.

Cancellation is rare in practice, because a Sprint is a month or less and ending one early seldom saves enough to justify the disruption. Work in progress returns to the Product Backlog, and the next Sprint begins with its own Sprint Planning like any other.

What cancellation is not is a remedy for a forecast that turned out optimistic. Discovering halfway through that the selected items were much larger than anybody thought is the empirical process working rather than failing, and it is handled by the ordinary machinery: the Developers adapt the Sprint Backlog and, if the Sprint Goal is threatened, renegotiate scope with the Product Owner, while the Sprint runs to its scheduled end. The exam tests exactly that line — a Sprint Goal that has become pointless against a plan that has become wrong.