Retrospective
A meeting where a team looks back at a milestone in a project or sprint, built into agile Scrum as standard.
A retrospective (often shortened to “retro”) is a meeting where a team looks back at a milestone in a project or sprint. It is a process for “looking back at the past and making use of it next time,” and it is built into agile Scrum as standard. In Japanese it is also called a “furikaeri-kai” (look-back meeting) or “KPT.” Having a regular place to look back gives you a chance to notice and act on problems in how work is done.
The basic structure of a retro
There are many frameworks, but a simple and widely used one is “KPT.” You look back along 3 axes: Keep (things to continue), Problem (issues), and Try (things to try next).
Frameworks other than KPT
| Name | Axes | Best suited for |
|---|---|---|
| KPT | Keep / Problem / Try | General purpose. Widely used |
| Start / Stop / Continue | Start / stop / continue | Action-oriented |
| 4Ls | Liked / Learned / Lacked / Longed for | Emphasizes feelings and learning |
| Mad / Sad / Glad | Anger / sadness / joy | When you want to be honest about feelings |
| Sailboat | Wind (driving force) / anchor (obstacles) / rocks (risks) / island (goal) | Emphasizes visuals |
Conditions for a retro that works
- Psychological safety is ensured (people are not blamed for what they say)
- Criticize the process, not individuals
- Concrete actions are decided under Try
- The previous Try is reflected in the next Keep / Problem
- Timebox it, aiming for about 30-60 minutes
Keeping it from becoming an empty formality
One reason a retro turns into an empty ritual that people feel forced into is that the Tries that come out are never carried out. As with meeting follow-up, you will want to build in a cycle where each Try becomes an action item with an owner and a deadline, and progress is checked at the start of the next retro.
Designing the frequency
In Scrum, it is held at the end of each sprint. A look back at the whole project (a project retro) is held every quarter or after a major release. Combine it with optimizing recurring meetings to balance frequency and quality.
The granularity of Try decides success or failure
The quality of a retro tends to depend on how concrete the Tries are. An abstract Try such as “improve communication” is something no one can carry out, and the same Problem shows up again next time. Break it down to a granularity, such as “set aside 5 minutes for questions at the end of the morning meeting,” that the owner can carry out starting tomorrow and that can be judged as done or not at the next retro. The same goes for Problems: if, as you continue, their resolution sharpens from overly large issues like “not enough resources” to specific snags in the process, you can read it as a sign that the retro has started to work.