Retrospectives That Change Something: From List to Delivery

Retrospectives change something when every agreed action gets an owner, a date, a place in the backlog and a test criterion. Most teams collect ideas in the retrospective and never work on them, because the list sits beside the real work. Teams that cap the number of actions and treat them like any other delivery improve their way of working sprint by sprint.

This article describes why retrospectives remain without consequence in many companies, what a format after Derby and Larsen looks like, which action card turns an idea into a delivery and which metrics show whether the retrospective works.

What is a retrospective for, and what does the Scrum Guide say?

A retrospective serves to review a team's way of working and to agree improvements for the next cycle. The 2020 Scrum Guide names as the purpose of the Sprint Retrospective to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regard to individuals and interactions, processes and tools as well as the Definition of Done, and it identifies the most helpful changes. The most impactful improvements are to be addressed as soon as possible and may even be added to the Sprint Backlog of the next Sprint. For a one-month Sprint the retrospective is limited to a maximum of three hours, and for shorter Sprints it is shorter.

The decisive sentence in the Scrum Guide comes at the end of the paragraph: improvements belong in the backlog. The retrospective is thereby tied to planning, and its result is work in the backlog. It can also be used outside Scrum: Kanban teams and business functions use the same format, as do leadership circles, when they look at their collaboration at fixed intervals. The article on agile rituals without effect describes how rituals lose their effect when they merely take place.

Why do retrospectives remain without consequence in many companies?

Retrospectives remain without consequence because their results have no place in work planning. Four causes recur.

The first cause is volume: a team collects ten to fifteen ideas and resolves to tackle all of them, and by the next retrospective none is done. The second is missing ownership: an action that “the team” owns belongs to nobody. The third is the absence of a criterion by which to see whether the action worked. The fourth concerns problems outside the team's power: when the biggest obstacle lies in a dependency or in a directive from leadership, the retrospective breeds frustration until someone escalates the topic.

Research on action planning explains the lever. In a 1999 review article Peter Gollwitzer described implementation intentions, plans of the form “if situation X arises, I will do Y”. In a meta-analysis by Gollwitzer and Sheeran (2006) covering 94 tests, such concrete plans raised the chance of reaching a goal compared with the bare intention, with a medium to large effect size. An action such as “we will communicate better” is an intention. An action such as “from Monday the product owner answers every question from development by noon the same day” is a plan.

How does an effective retrospective run?

An effective retrospective follows five phases that Esther Derby and Diana Larsen described in “Agile Retrospectives” (2006). The phases give the session a dramaturgy and prevent the team from jumping straight into solutions after the first contribution.

1. Set the stage: the team arrives, and the ground rules and the goal of the session are stated. In “Project Retrospectives” (2001) Norm Kerth describes a basic assumption that helps: everyone did their best with what they knew at the time.
2. Gather data: the team collects facts, such as metrics and events from the cycle. Methods include a timeline or the formats “Start, Stop, Continue” and “Sailboat”.
3. Generate insights: the team asks for causes. The five whys method, which originated in Toyota production, leads from a symptom to its root.
4. Decide what to do: the team selects two actions at most and writes them as an action card.
5. Close: the team reviews the session itself and clarifies where the actions sit in the backlog.

The choice of format and method is secondary, whereas the phases are binding. Anyone who shortens the fourth phase produces a list again.

What belongs on an action card?

An action card turns an idea into a delivery. It holds six entries that together mirror the if-then pattern of action planning.

The test criterion closes the loop. It lets the next retrospective say whether the action worked or must change. This corresponds to the cycle of plan, do, check and act associated with Walter Shewhart and W. Edwards Deming, and to the improvement kata of Mike Rother (“Toyota Kata”, 2009), in which teams approach a target condition in small steps.

How many actions can a team handle?

A team can handle one or two actions per cycle, because improvement work competes with delivery work for the same capacity. Anyone who agrees more exceeds what is feasible, as the article on limiting work in progress shows for any kind of work. Improvements therefore get an estimate like any other task and compete with features in the backlog. The product owner decides together with the team, and the decision is recorded in the planning session.

A simple measuring tool shows whether the retrospective works and consists of two metrics:

If the completion rate stays below 50 per cent over several cycles, the number of actions is too high or the place in the backlog is missing. If the effect rate is low, symptoms were treated instead of causes, and the third phase deserves more time.

What if the obstacle lies outside the team?

If the obstacle lies outside the team, it becomes a topic for the next level up and gets the same owner and date as any action, plus a metric. In the retrospective a team names the topics it cannot solve itself and hands them, with a description of impact and frequency, to the responsible body, such as the leadership group or a coordination forum. The article on the sprint review describes how decisions with stakeholders can be prepared. Leadership answers the topics within a fixed period, otherwise the retrospective loses its credibility. For companies that have used Scrum for some time, the article on Scrum in mid-sized companies places the experience after the first year.

Embedding retrospectives in delivery with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the service area of delivery management he works as delivery manager, project manager or product owner and ensures that improvements from the teams arrive in the organisation.

The approach follows the Niehues Delivery Model with its three phases. For retrospectives three test questions matter most: Who decides, who delivers, who uses? Which roles and decision paths does operations need? Which metric shows after 90 days that the solution has landed? The entry point is a free initial consultation of 30 minutes, which you can arrange via the contact page.