KPT retrospective: Keep, Problem, Try

Keep what works, name the problems, and pick one or two small things to try before the next retro. KPT is the shortest path from a retrospective to a change in how the team works.

Keep

What should we continue because it works?

Problem

Issues or friction we hit—name the pain clearly

Try

Small experiments or changes to attempt next

Use this template — it's free

What a KPT retrospective is

KPT stands for Keep, Problem, Try. The team writes down the practices worth continuing, the problems and friction it ran into, and small experiments to attempt in the next cycle. Then it picks the problems that hurt most and agrees on one or two tries to run before the next retro. The format is often traced to the reflection workshop Alistair Cockburn described in Crystal Clear, and it is especially popular with software teams in Japan.

The idea behind it is a loop. Every try is an experiment with a short horizon. At the next retro you look at it again: if it worked, it moves to Keep; if it didn't, you drop it, and the problem gets a different try. After a few sprints, the Keep column becomes an honest description of how your team works — built from experiments that survived, not from a process someone wrote down once.

Why teams choose it over other short formats:

• It separates the problem from the fix. In Start Stop Continue, people tend to jump straight to "start pairing on reviews" before anyone agrees what is wrong. KPT asks you to name the pain first, so the team can check that it is real before choosing a remedy.
• A try is cheap to agree to. It is not a promise to change forever, only an experiment for a sprint or two. People accept a change more easily when they know it can be undone, and the team learns faster because it runs more experiments.
• "Problem" is neutral. It points at the work. A "Stop" card can read like an accusation aimed at whoever does the thing.
• It needs no explanation. Three plain words, no metaphor. A team on one-week sprints can run it in half an hour and still leave with something to do.

When to use it, and when not to

KPT fits teams that want a retro to produce change, regularly and without ceremony:

• short sprints, where a long format every week or two would eat too much time;
• busy periods, when you need a retro that delivers something in 30–45 minutes;
• a team whose retros produce long action lists and little change — tries are small by design, and the next retro checks them;
• as the team's default format between more exploratory sessions.

Pick something else when:

• Feelings matter more than fixes. After a hard release, a reorganization or a conflict, the Problem column reduces everything to something fixable, and people feel unheard. Start with Mad Sad Glad.
• The real question is direction. If the team is unsure where it is heading, small tries will polish the wrong things. The Sailboat puts the goal on the board first.
• Your process has grown too big. When meetings, tools and rules have piled up, a review of the whole set works better than a problem list. Use the DAKI retrospective to decide what to drop.

The three columns

In ProstoRetro the board opens with Keep, Problem and Try. Here is how to fill each one, with cards a product team might write after a two-week sprint.

Keep: what works

Practices the team should continue because they work. The test: it happened in this cycle, it helped, and you would notice if it stopped. Keep is also where last sprint's successful tries graduate. Do not skip it in a hurry to get to the problems — saying out loud what works protects it from the next well-meant change of process.

• Pairing on support escalations: fixes now go out the same day
• Release notes written in the pull request, not the night before release
• No meetings on Thursday afternoons
• Last retro's try — a ten-minute demo for support before each release — keep it

Problem: where it hurt

Issues and friction the team hit, named clearly. A good problem card says what happened and what it cost. The test that separates it from a try: a problem is something that happened; a try is something you will do. "We need more tests" is a solution wearing a problem's clothes. "Two bugs reached production because nobody checked an empty cart" is a problem the team can discuss.

• Three tickets bounced back from QA because they had no acceptance criteria
• The deploy queue blocked everyone for half a day on Wednesday
• Standup runs 25 minutes; most people tune out after ten
• We learned about the API change from a customer, not from the platform team

Try: the next experiment

Small experiments or changes to attempt next. The test for a good try: can you start it before the next retro, and will you know by then whether it worked? If the answer to either is no, make it smaller. "Fix the CI pipeline" is a project; "move the slowest test suite to a nightly run for one sprint" is a try.

• Write acceptance criteria together during refinement for two sprints, then count the bounced tickets
• Standup walks the board from right to left, with a hard stop at 15 minutes
• Merge small changes behind feature flags for a sprint and see if the deploy queue shrinks
• One of us joins the platform team's weekly sync for a month

Use this template — it's free

A 45-minute KPT agenda

For a team of four to nine people. If you have only half an hour, use the cut-down version below the list.

1. Warm-up, 3 minutes. One quick question from our list of icebreaker questions, so everyone has spoken once before the real work.
2. Review last time's tries, 5 minutes. For each one: did it work, and what do we do with it — keep it, adjust it or drop it? ProstoRetro opens the retro with the open action items from the previous one, so the list is on screen and nobody has to dig through notes.
3. Silent writing, 8 minutes. Cards in all three columns. Encourage people to add a try for each problem they write, but do not require it — a clearly named problem is useful on its own. Cards stay hidden until writing ends.
4. Grouping, 5 minutes. Merge duplicate problems and move each try next to the problem it would solve. With many cards, accept the app's AI grouping suggestion and adjust it by hand.
5. Voting, 4 minutes. Vote for the problems that cost the most and the tries you would back. Votes are anonymous, so a junior developer can back a different try than the lead.
6. Discussion, 15 minutes. Take the top two or three problems. Spend the first couple of minutes on each confirming that everyone sees the same problem, then pick a try from the cards or design a new one.
7. Commit to tries, 4 minutes. Two tries at most. Each gets an owner, a due date — usually the day of the next retro — and the signal you will check.
8. Close, 1 minute. Read the Keep column aloud. Ending on what works is a better send-off than ending on a list of problems.

The 30-minute version, for one-week sprints or a crowded week: skip the warm-up, give writing five minutes, spend a minute on grouping when there are only a dozen cards, and choose a single try. It works because the loop is short — you will be back next week to check.

In either version, enter the meeting length when you create the board. ProstoRetro shares the minutes out between the phases and starts each timer, which helps most when every minute counts.

Remote facilitation tips

• Let reminders keep the experiment alive. A try is an action item with an owner and a due date. The owner gets an email reminder a week after the retro and another before the due date, so an experiment does not quietly expire in the middle of a sprint.
• Time-box agreement on the problem. Remote discussions drift into solutions early. Give each problem two minutes of "do we all see it?" before anyone proposes a fix. If the team cannot agree in two minutes, the problem probably needs data first — and collecting it can be the try.
• Settle a split with a poll. When two tries compete for the same problem, an anonymous single-choice poll shows the team's preference in a minute, without the loudest voice deciding.
• Keep problems anonymous when they need to be. Anonymity is the default for cards; anyone who wants credit can sign theirs. Problems that involve a manager's decision or another team's work come up more easily that way.
• Watch the trend, not one sprint. Run the anonymous pulse survey at the start of each retro. The team page keeps its history, so after three or four rounds of tries you can see whether the team actually feels the difference.

Variations

Add an Action column

Some teams add a fourth column, Action, to separate the experiments they discussed from the ones they committed to (you may see this written as KPTA). In ProstoRetro you can build it as a custom template with up to five columns, each with its own description and color.

KPT on one topic

Point the whole session at a single area: code review, on-call, the hiring process, how the team works with design. Narrow scope gives deeper problems and more precise tries than a general sprint review.

Personal KPT

The same three questions work for one person reviewing their own week or preparing for a one-to-one. Keep a running list, and look at how many tries made it into Keep over a month.

Common mistakes

• A complaint wall. Problem cards that name an annoyance without its cost are hard to prioritize. Ask "what did it cost us?" for every top problem.
• Tries that are really projects. "Rewrite the deployment pipeline" will not fit before the next retro, so it will not be reviewed there. Cut it down to the first step you can measure.
• Too many tries at once. With five changes running, you cannot tell which one helped. One or two per retro is enough.
• Never checking the tries. Without the review at the start of the next retro, KPT is just another list of good intentions.
• An empty Keep column. If nothing is worth keeping, the team either is in real trouble or is not looking. Both deserve a conversation.

FAQ

What does KPT stand for?

Keep, Problem, Try: what the team should continue because it works, the issues it ran into, and small experiments to attempt next.

What is the difference between KPT and Start Stop Continue?

Start Stop Continue asks for actions straight away. KPT names the problem first and treats each change as an experiment to check at the next retro, which makes it easier to agree on and to learn from.

How many tries should come out of a KPT retro?

One or two. Few enough that the team can actually run them and tell at the next retro whether they worked.

How long does a KPT retrospective take?

45 minutes for most teams, as in the agenda above, and about 30 minutes for weekly sprints if you keep it to the single biggest problem.

Can I run a KPT retrospective online for free?

Yes. Pick KPT when you start a board in ProstoRetro; it costs nothing, and the tries you save as action items are waiting at the start of the next retro. The guide on how to run a great retro walks through the app, and the retrospective templates library has the other formats.