How to Run a KPT Retrospective: Three Boxes That Turn a Finished Run into Next Time's Prep

A KPT retrospective looks back on finished work in three boxes: Keep (what to keep doing), Problem (what went wrong), Try (what to do differently next time). With only three boxes it takes about ten minutes, and because the last box ends on what you will change, the review doesn’t stay a feeling.

It fits best when you repeat the same kind of work. A class you run every session, a customer interview you do again and again, an episode you shoot every week — when the next run is certain to come, this run’s Try is the next run’s preparation.

The three boxes

• Keep — what to keep doing. What went well and should stay. Not “it went well” but what you did that made it go well.
• Problem — what went wrong. Where you got stuck, ran short, or were surprised. Write what happened, as fact.
• Try — what to do next time. The action you will take differently to shrink a Problem or strengthen a Keep.

The format comes from the three columns software developer Alistair Cockburn used in his reflection workshops (Keep these / Problems / Try these), and it spread widely in Japan under the name KPT. It started as a team practice, but it works just as well alone.

How to write one: ten minutes, three steps

Right after you finish is best. A day later you still remember “we ran short on materials” but no longer remember by how many.

1. Start with Keep (3 minutes). There is a reason to begin with what worked. Start with problems and there’s no energy left for the good parts — and a Keep you didn’t write down is one you’ll drop by accident next time.

2. Write Problems as facts (3 minutes). Not “the pacing was sloppy” but “part two started 15 minutes late.” It has to be an observation, not a verdict, or the next box can’t turn it into an action.

3. Attach one Try to each Problem (4 minutes). A Try is not a resolution. It is a sentence that goes into next time’s materials or sequence. “Manage time better” is not a Try. “Set an alarm ten minutes before part one ends” is.

Example: after session 3 of a candle class

Keep	Pre-portioned the materials per person — setup was done in five minutes
Problem	Two wicks short · choosing scents ran long, which cut curing time by 20 minutes
Try	Pack wicks at headcount + 3 · set out only six scent samples and give ten minutes to choose

Those two Try lines go straight into the materials list and the run-of-show for session 4. The retrospective isn’t finished until they do.

Writing a good Try

• Make it a sentence you can put into next time’s prep. For materials, include the quantity. For sequence, include the moment.
• For a Try that depends on a situation, use if-then. “If choosing scents passes ten minutes, then the people still choosing pick between two.” Written this way, you don’t have to decide again in the moment. We covered the form in detail in Implementation Intentions.
• Keep the count low. Five Problems still means only the two or three Tries you’ll actually do next time. Leave the rest in Problem — they’ll show up again in the next review.

Common mistakes

• A long Problem list with no Try. A list of problems doesn’t change the next run. A Problem without a Try is half-written.
• Skipping Keep. What worked feels obvious, so it doesn’t get written — and then you forget why it worked.
• Leaving the Try inside the retrospective document. If you don’t reopen that document when you start preparing the next run, the Try never happened. Move each Try into next time’s materials or sequence at the moment you write it.
• Not checking last time’s Try. The next retrospective starts with “did I do last time’s Try, and did it help?” If it helped, it moves up to Keep.

How it differs from an After Action Review

A close relative is the After Action Review (AAR), which began in the US Army. It has four questions: what was supposed to happen, what actually happened, why was there a difference, and what will we do differently next time.

Both arrive at the same place. An AAR starts from the gap between what was planned and what occurred, so it suits work with a clear plan. KPT has fewer boxes and is faster to write. Either way the core is the same: look back through fixed questions, and end on the next action.

There is evidence for this. In a meta-analysis of 46 studies (Tannenbaum & Cerasoli, 2013), individuals and teams that ran structured debriefs performed on average 20–25% better than those that didn’t. The condition was the structure — answering set questions rather than loosely recalling how it went.

Where the review crosses into the next preparation

The place KPT most often breaks is the path from Try to the next run’s preparation. When the review lives in one document and the preparation lives somewhere else, a person has to carry it across every time.

In fecit, the app we’re building, work you repeat lives as a template, and each run is a task made from that template. When you finish a task you write what you saw in its retrospect field. If you put the three lines “Keep / Problem / Try” in the template’s retrospect field, every task made from that template starts with the three boxes already written.

When a Try changes your materials or sequence, template improvement lets you pick those changes and send them back into the template. The next run’s task starts from the corrected preparation.

Whatever tool you use, the order is the same. Ten minutes right after you finish, three boxes — Keep, Problem, Try — and then move each Try into next time’s preparation.