One sentence to agree on before you start
Norman Kerth's Project Retrospectives (2001), the classic of retrospective practice, asks the whole room to agree on one premise before starting: regardless of what we discover, we truly believe everyone did the best job they could, given what they knew at the time, their skills, the resources available and the situation at hand. It is known as the retrospective Prime Directive.
There is a hard reason this is not a nicety. The moment a retro becomes a place where fault is assigned, people stop naming problems and start hiding them, and from the next retro on the real problems never reach the table. No-blame is not about being nice; it is the device that protects the data a retrospective runs on.
What each of the three columns does
KPT grew out of the reflection workshop format by Alistair Cockburn, a co-author of the Agile Manifesto (what to keep, ongoing problems, what to try next), and settled into its current name in the Japanese developer community. With only three columns, a first-time team barely needs to learn any facilitation.
- Keep: what to continue. Write what went well and why it worked.
- Problem: recurring issues. Write the pattern, not a single incident.
- Try: what to attempt next period. Pick from Problem and turn it into an experiment.
Why Keep comes first
Going through the good things first is not about warming up the room. Most things that went well are somebody's repeatable behavior, not luck, and unless they are named they quietly disappear next period. If posting an incident to the shared channel early made the response fast, that is not a compliment, it is a process to keep.
A team whose Keep column is always empty is probably setting the bar too high. It does not take an achievement; anything you would want to do the same way next time belongs in Keep.
Problems point at the process, not the person
The same problem, written two ways, makes or kills a retro. A sentence whose subject is a name becomes an accusation; a sentence whose subject is a process becomes something to improve. Stripping adjectives and replacing them with measurable facts helps too.
A Try is an experiment, not a resolution
This is where retrospectives die into talk. A Try like communicate better or be more careful changes nothing. A good Try has the shape of an experiment: what, until when, and how it will be checked, so the next retro can rule on keeping it or dropping it.
Count matters too. A team that picks five Tries usually lands zero. Choose the single most painful Problem and narrow it to one or two experiments. Retro after retro, the team accumulates rules that survived testing. That accumulation is the actual output of retrospectives.
The 60-minute agenda
For a team just adopting the format, 60 minutes is enough. Whether on sticky notes or a shared document, the trick is separating silent individual writing from reading together.
| Time | Activity |
|---|---|
| First 5 min | Check what happened to the last retro's Try |
| 10 min | Write Keep individually, then read together |
| 20 min | Write Problems, cluster similar ones, vote on the most painful |
| 20 min | Turn the chosen Problem into Try experiments (owner and deadline included) |
| Last 5 min | Tidy the record, fix the date of the next retro |
Frequently asked questions
How often should we hold retrospectives?
At the end of every sprint, or every two weeks, works for most teams. If retros only happen after a major incident, the word retro becomes a synonym for inquest. Teams that run short retros routinely catch problems while they are still small.
How does this work for a remote team?
Open the same document and separate the silent writing phase with an explicit timer, and it runs almost like being in one room. For quieter teams, keep the writing anonymous and attach names only from the discussion onward. The most common remote failure is skipping the writing phase because silence on a video call feels awkward.
The same Problem keeps coming back every retro.
It is one of two things: the Try never became a real experiment so nothing changed, or the problem sits outside the team's authority and a retro cannot solve it. For the first, slice the Try smaller. For the second, mark it in the record as an outside-the-team issue and make delivering it to someone with authority part of the retro's job. If you are writing the same problem for the third time, the moment calls for a different channel, not another retro.