KPT Retrospective Template: Keep, Problem, Try

KPT asks three questions: what should we Keep, what's a Problem, and what will we Try next? It's built around one move: every top Problem gets a matching Try, and the team picks one or two Tries as experiments for the next sprint. At the next retro, each Try either becomes a Keep or goes back to being a Problem. That loop makes KPT good at building a habit of small, checked experiments.

The three columns

A Try is an experiment, not a promise. It has a time limit (usually one sprint) and a way to tell whether it worked. "Improve staging" isn't a Try. "Rotate a staging owner for one sprint and count hours of downtime" is.

Where it comes from. The three lists match the reflection workshop Alistair Cockburn describes in Crystal Clear (Addison-Wesley, 2004): the team fills a flipchart with what to keep, its problems and what to try, then posts it where everyone works. The acronym KPT caught on in Japan's agile community, where it's still one of the most common retro formats. Nobody is credited with the name.

When to use it (and when not to)

Use it when:

• you want every retro to end with one or two experiments, not a list of wishes
• the team agrees on fixes and never checks them. KPT builds the check into the next retro.
• the same problems keep coming back. One that returns after two Tries stands out.
• you need a short, plain format that a new joiner understands in a minute

Pick something else when:

• one big problem has an unclear cause, such as an outage. KPT jumps from problem to fix; use 5 Whys first.
• people need to talk about how the sprint felt. Try Mad Sad Glad.
• the changes are adjustments, not experiments: more pairing, fewer meetings. Starfish has columns for that.

How to run it live (30 minutes)

1. Close last sprint's experiments. Open the Previous Retro tab in the Action Items panel, and glance at Old / Unresolved Items. For each Try: did we do it, and did it help? Add a Keep or a Problem note for each.
2. Write Keep and Problem only. Set the shared timer for seven minutes. Leave Try empty for now.
3. Group. Drag duplicate Problems onto each other.
4. Vote on Problems, then sort by Most Votes.
5. Write Tries for the winners. Everyone adds Try notes for the top Problems, three minutes. Then discuss: which is cheapest, and how will we know it worked?
6. Pick one or two. Each becomes an action item with an owner. The rest stay on the board as ideas.

How to run it async over a sprint

Problems are easiest to describe the day they happen: what broke, when, and what it cost.

1. Day 1: the next board is ready once someone clicks Start New Retro after the last retro. The Tries you picked show in the Previous Retro tab, so everyone sees what's being tested.
2. During the sprint: add Keep and Problem notes as things happen, on the board, in Quick Notes on the Team Room page, or with /retro your note if the team uses Slack. Hold Tries until the end.
3. Mid-sprint: the facilitator checks on the current Tries. If one was dropped after two days, that's a Problem note worth writing now.
4. Two days before the end: everyone votes on Problems, then adds a Try note for the top ones, naming the Problem it answers.
5. The day before: the facilitator groups Tries that answer the same Problem and reads the CarrotIQ Sprint Summary.
6. Retro day: a 15-minute call to pick one or two Tries and owners. Or fully async: the facilitator proposes the top Try for each top Problem, and owners accept in writing.

More in how to run an async retrospective.

10 example prompts

Keep

1. Which Try from last sprint should become a habit?
2. What went smoothly that we'd miss if it stopped?
3. What did someone do this sprint that the whole team should copy?

Problem 4. Where did work wait, and for how long? 5. What surprised us late in the sprint? 6. Which problem from an earlier retro is back? 7. What did we work around instead of fixing?

Try 8. What's the smallest change that would make this Problem less likely? 9. What could we test for one sprint and drop if it doesn't help? 10. Who outside the team could help, and what would we ask them?

Facilitator tip and a common pitfall

Tip: don't mix the Problem and Try steps. When people write Tries alongside Problems, each person proposes a fix for their own Problem and the votes split. Vote on Problems first, then write Tries only for the winners. You get several Tries per Problem to choose from.

Pitfall: never closing the loop. The cycle only works if every Try comes back. Skip the first five minutes and you collect Tries nobody remembers agreeing to. If time is short, cut discussion, not the review of last sprint's Tries.

How AI helps with this format

On Pro AI (and during the free trial), CarrotIQ takes care of the admin:

• Group names. Drag "staging down again" onto "couldn't test checkout" and CarrotIQ names the group, for example "Staging Reliability".
• Summaries. The Sprint Summary covers each column plus the whole retro. A few sprints of Problem summaries show which Problems came back after a Try.
• Suggested action items. CarrotIQ Suggest drafts an action from the notes, weighting the most-voted ones and skipping actions you already have. When the team is stuck on a Try, start from the draft, then edit and assign it.

Example action items

Each Try needs an owner, a time limit and a check.

Next retro, the Previous Retro tab lists these; older open ones sit under Old / Unresolved Items. More in retrospective action items that actually get done.

Use this template in Retro Rabbit

1. Start a 14-day free trial. No card is needed.
2. Pick KPT (Keep, Problem, Try) from the format library: choose "Browse all formats" when you create your Team Room, or later in the Team Room's Settings.
3. Start every retro by turning each item in the Previous Retro tab into a Keep or a Problem note, before anyone writes anything new.

See pricing for plans.

Related formats

• Plus / Delta: two columns and 15 minutes, for after any meeting
• Start Stop Continue: when you want behavior changes rather than experiments
• Starfish: when the fixes are adjustments, not experiments
• 5 Whys: when a Problem needs a root cause before a Try
• More formats in Kanban and lean
• All retrospective templates