What to Do After a Sprint Retrospective

After a sprint retrospective, test the assumptions behind each action item, and behind the team's account of what went wrong, before either goes into the next sprint. The retrospective hunts for the assumptions that failed last sprint but has no step for the new ones the team is about to adopt. Between 2011 and 2013, the largest agile program in the NAO's 2012 survey of government was reviewed repeatedly, changed its method twice, and still wrote off £34 million of new IT.

A sprint retrospective is the Scrum event that closes each sprint, where the team inspects how the sprint went and agrees changes to improve its effectiveness.

What a sprint retrospective delivers

The Scrum Guide gives the retrospective one purpose: to plan ways to increase quality and effectiveness. The team inspects individuals, interactions, processes, tools and its Definition of Done. It is timeboxed to a maximum of three hours for a one-month sprint, and the most impactful improvements can go straight into the Sprint Backlog for the next sprint.

A widely used structure comes from Esther Derby and Diana Larsen in Agile Retrospectives (2006), in five phases: set the stage, gather data, generate insights, decide what to do, and close. The data comes from the sprint just finished. The insights explain it. The decisions become a short list of action items, each with an owner.

The cadence is the real asset. A team running two-week sprints reviews its own work roughly twenty-six times a year. Compared with lessons-learned exercises held when a project closes, the retrospective catches problems while the team that met them can still act. It is a feedback loop short enough to act on.

The format also protects candour. Norm Kerth's Prime Directive, often read aloud at the start, asks everyone to accept that each person did the best job they could with what they knew at the time. Blame is taken off the table so that problems can be named. The military version of the same idea is the after-action review, and the gap described after an after-action review has the same shape.

What leaves the room is a shared account of the last sprint and a list of changes for the next. Both look like conclusions. Both are claims about the future that have not yet been checked against it.

What it leaves unexamined

The Scrum Guide contains a telling sentence: "Assumptions that led them astray are identified and their origins explored." The inspection points backwards. It hunts for the assumptions that failed during the sprint just finished. The action items point forwards, and each one carries assumptions of its own. The retrospective audits last sprint's assumptions and creates new ones for the next.

Start with the diagnosis. "Stories were too big" is a common explanation for a missed sprint goal. It is also a hypothesis. It gets onto the board because several people found it plausible, and dot voting then ranks it above the alternatives. A vote measures how many people believe a cause, not whether the cause is real. The same weakness runs through cause analysis generally, and the step that should follow root cause analysis is the same test.

Then the fix. "Split every story over five points" assumes size caused the miss, that splitting will not add coordination cost, and that the effect will be visible within one sprint. None of that is tested before the change enters planning. Sometimes the board itself holds the evidence against the diagnosis, sitting two columns apart.

Both cards can sit on the same board without anyone reading them together. If the reopened stories counted towards velocity, the "went well" column rests on the assumption that done meant done. The team leaves with an action item about testing, and a diagnosis nobody checked against its own data. No step in the event asks what would have to be true for a change to work, or how the team would know by the next retrospective.

Pick the action item your team voted highest and write down what has to be true about last sprint for it to fix the problem. Start the Walk →

When the gap cost Universal Credit £34 million

In late 2010 the UK Department for Work and Pensions chose an agile approach for Universal Credit, a single benefit replacing six. Its £2.2 billion budget topped the NAO's 2012 snapshot of agile projects across 16 government organisations. The Department planned national roll-out from October 2013. Its own estimate put a waterfall approach at April 2015, and it could not explain to the NAO how it had settled on October 2013.

The program was reviewed constantly. Internal audit, the Major Projects Authority and supplier-led "red team" reviews reported through 2011 and 2012. The Department answered with changes to method. It moved to "Agile 2.0" in January 2012, then to a phased approach with separate directors from October 2012 after suppliers questioned whether the date was achievable. The Cabinet Office judged that, before the reset, it had never appropriately adopted agile. The sequence still behaved like a run of retrospectives at program scale.

The reviews kept circling a gap the method changes never touched. The NAO's September 2013 report found the Department had been warned repeatedly that it lacked a detailed blueprint of how Universal Credit would work. It failed to fully implement two-thirds of the 2012 recommendations from internal audit and the Major Projects Authority. Reviews in mid-2012 found a "fortress" mentality and a "good news" reporting culture that stifled challenge.

In February 2013 the government ordered a thirteen-week reset. By May the Department had written off £34 million, 17 per cent of its new IT assets, and work on national roll-out from October 2013 had stopped. The limited pathfinder running instead handled only the simplest new claims, according to the full report. Changing the method answered each review without testing the assumption behind it.

One step before the next sprint

The insertion point sits between the retrospective and sprint planning, before any action item enters the Sprint Backlog. Each action item is a small decision, not a conclusion, and the five-step Universal Decision-Making Method gives it a structure that fits inside a sprint.

Frame the problem the action is meant to solve and what the next sprint is for, which is a problem framing task before it is a process one. List the Tentative Elements: the candidate changes, including leaving things as they are. Surface the Assumptions, starting with the diagnosis and moving to capacity and timing, and write them down beside the action item.

Decide what Sufficient Certainty looks like. A tweak to stand-up format needs little evidence. A change to the Definition of Done or the team's structure needs more. Then Implement and Monitor: name the signal that will show at the next retrospective whether the change worked, and treat monitoring as part of the action rather than an afterthought.

Two checks cost little. Rewrite each agreed cause as a prediction, "if stories were too big, the missed items will be the largest ones", and check the sprint data before planning. Then open the next retrospective with the previous action items and their written assumptions instead of a fresh board.

The same loop applies after an MVP launch, and it sits at the centre of decision quality. A retrospective that tests its own conclusions turns a ritual into a record the team can learn from.

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.