Keep, Problem, Try retrospective template

Three columns that chain together: what to keep, what hurts, and the experiment you run next.

Keep, Problem, Try — usually shortened to KPT — is a three-column retrospective where the team lists what is working and should continue (Keep), what is getting in the way (Problem), and what it will try in response (Try). The format is a staple of Japanese software teams, where it is known simply as KPT, and it has spread widely because the three columns are causally linked rather than independent buckets.

The distinguishing rule is what happens to Try. A Try is an experiment for one sprint, not a permanent policy. At the next retrospective, every Try is reviewed and gets a verdict: it worked and moves to Keep, it did not and is dropped, or it needs another sprint. Teams that skip that review get a Try column that grows forever and changes nothing.

Timebox

30–45 minutes

Team size

3–12 people

Cadence

Every sprint — the format depends on reviewing last time’s Try items

The Keep, Problem, Try board

Keep

What is working and should continue? Include Tries from last sprint that proved out.

  • Daily 10-minute standup with a hard stop
  • Pairing on the payment service — knowledge is spreading
  • The PR checklist we tried last sprint; reviews are faster
  • Writing tickets with acceptance criteria before planning
  • Deploying small and often instead of a Thursday batch
  • Blocking Wednesday afternoons for focused work

Problem

What got in the way? Describe the problem and its cost, not the solution yet.

  • Code review took three days on average; two tickets missed the sprint
  • Flaky tests were rerun 14 times this sprint
  • Requirements changed twice mid-sprint with no re-scoping
  • Only one person can deploy the reporting service
  • Standup runs 25 minutes because it turns into problem-solving
  • Nobody looked at the action items from the last retro

Try

What one experiment do we run next sprint? Small, specific, and reviewable in two weeks.

  • Try a two-reviewer rota so no PR waits more than one day
  • Try quarantining flaky tests instead of rerunning them
  • Try a mid-sprint scope check on Wednesday
  • Try pairing on every reporting-service deploy for two weeks
  • Try a parking-lot list in standup for anything over a minute
  • Try opening every retro with last sprint’s Try items

How to run a Keep, Problem, Try retrospective

  1. 1

    Review last sprint’s Tries (5 min)

    Open with the Try column from the previous retrospective. Give each one a verdict: it worked and moves to Keep, it did not work and is dropped, or it needs one more sprint. This step is what separates KPT from a list-making exercise.

  2. 2

    Fill Keep and Problem (8–10 min)

    Silent writing in both columns at once, cards hidden. Ask for the cost in the Problem column — "reviews took three days and two tickets slipped" is actionable in a way that "reviews are slow" is not.

  3. 3

    Reveal and group (5 min)

    Reveal everything and cluster. Read the Keep column aloud first: teams under pressure skip straight to problems, and losing sight of what works is how good practices quietly get dropped.

  4. 4

    Vote on problems (3 min)

    Each person gets 3 votes on the Problem clusters. You are choosing which problems get an experiment, so the votes decide the sprint’s process work.

  5. 5

    Design the Tries (10–15 min)

    For the top 2–3 problems, agree on one experiment each. A good Try names what changes, who owns it, and what you will look at in two weeks to decide whether it worked.

  6. 6

    Commit and close (3 min)

    Read the Try list back — no more than three items — with owners attached, and put it somewhere the team sees it during the sprint, not only at the next retro.

KPT examples for engineering teams

Keep

  • Feature flags on every risky change
  • The one-page incident write-up habit
  • Refinement before planning, not during

Problem

  • The build takes 22 minutes, so people batch pushes
  • Two production issues came from untested config changes
  • Tech-debt tickets never survive prioritisation

Try

  • Try caching dependencies in CI and measure the build time next sprint
  • Try requiring a config diff review before merge
  • Try reserving 10% of sprint capacity for debt and see if it holds

KPT examples for scrum and delivery teams

Keep

  • Sprint goal written as one sentence everyone can repeat
  • Demo to real stakeholders, not to the team
  • Capacity planning that accounts for support duty

Problem

  • Three tickets rolled over for the third sprint running
  • Planning takes 90 minutes because tickets arrive unrefined
  • The definition of done is interpreted differently by each pair

Try

  • Try re-scoping anything that rolls over twice instead of carrying it
  • Try a 30-minute refinement two days before planning
  • Try writing the definition of done on the board and referring to it in review

KPT examples for remote and cross-functional teams

KPT travels well asynchronously because the columns are unambiguous — people can fill Keep and Problem on their own time, and only the Try discussion really needs everyone live.

Keep

  • Written updates in the team channel by end of day
  • Recorded demos with time-stamped highlights
  • Overlap hours protected for decisions

Problem

  • Decisions made in calls never reach the two people in other time zones
  • Handovers between design and engineering lose context
  • The retro board is filled by the same four people

Try

  • Try posting a written decision summary within an hour of every call
  • Try a five-minute recorded handover walkthrough per ticket
  • Try async card collection over two days before the live session

Best for

  • Teams that want small experiments rather than sweeping process changes
  • Sprint retros where the same problems keep resurfacing unaddressed
  • Teams new to retrospectives — three prompts, no metaphor to explain
  • Anyone whose action items pile up because nothing is ever closed out

Facilitation tips

Open every retro with last sprint’s Tries

This is the format’s engine, not a formality. Reviewing Tries gives the team evidence about its own changes and keeps the Try column from turning into a wish list nobody revisits.

Three Tries, maximum

A Try is an experiment the team runs alongside its actual work. Two or three fit in a sprint; six means none of them get real attention and the next retro has no evidence to review.

Put the cost in the Problem card

"Reviews are slow" gets nodding. "Reviews took three days and two tickets missed the sprint" gets an experiment. Ask what the problem cost — in time, rework, or missed commitments — before moving to Try.

Let Tries fail out loud

A Try that did not work is a useful result, not a failure of the team. Saying so plainly makes the next round of experiments bolder; quietly dropping failed Tries teaches people the whole exercise is theatre.

Variations

KPTA (adds Action)

Splits Try into the idea and the concrete action with an owner and a date. Worth adopting when Tries keep being agreed and then not actually run.

Rolling KPT board

Keep one board across sprints instead of starting fresh: Tries physically move into Keep or off the board. The history makes trends visible — including problems that reappear every sprint under a new card.

Problem first

Some facilitators collect Problems first, then ask what to Keep, so the positives are not written as a warm-up before the "real" column. Good for teams that treat Keep as a formality.

Async KPT

Collect Keep and Problem cards over two days, cluster and vote beforehand, then meet for 20 minutes only to review last sprint’s Tries and design the new ones.

Frequently asked questions

What is a KPT retrospective?+

KPT stands for Keep, Problem, Try. It is a three-column retrospective where the team lists what is working and should continue, what problems got in the way, and what experiments it will try next sprint in response. The columns are linked: Tries address the voted Problems, and successful Tries become Keeps at the following retrospective.

What does each KPT column mean?+

Keep is practices worth continuing, including experiments from last sprint that proved out. Problem is what got in the way, ideally with the cost attached. Try is the small experiments the team commits to for the next sprint — reviewed, not assumed permanent.

How is KPT different from Start Stop Continue?+

Start Stop Continue asks for behaviour changes directly in three parallel columns. KPT is sequential: you name problems first and then design experiments for the ones the team voted on, and each experiment is explicitly reviewed next time. KPT suits teams that want to test changes; Start Stop Continue suits teams ready to just decide.

How many Try items should a team commit to?+

Two or three. Tries run alongside normal delivery work, so a longer list means none of them get real attention — and the next retrospective has nothing solid to review.

Where does KPT come from?+

The format is most strongly associated with Japanese software teams, where KPT (Keep / Problem / Try) is one of the standard retrospective formats, and it spread internationally through agile and lean practice. Its structure closely mirrors the plan-do-check-act improvement cycle.

Run Keep, Problem, Try online in FocusRetro

Start a blank board, name the columns Keep / Problem / Try, and invite the team with a link — then run the phases with timers, hidden cards, and blind voting. Free plan available at focusretro.com.

Start a board free

No credit card required

Related guides

Start, Stop, Continue retrospective template

The fastest way to turn team feedback into concrete behavior changes.

Open the Box retrospective template

Treat how your team works like a box of tools — then decide what stays, goes, and gets added.

Release retrospective template

The retro for a whole release: timeline first, then the three things that change before the next one.

How to run a sprint retrospective (step-by-step guide)

A step-by-step sprint retrospective guide: the 5-phase agenda, exact timings for a 60-minute session, facilitation tactics, remote tips, and common failure modes.

What is a retrospective? The complete guide for teams

A retrospective is a recurring team meeting for inspecting how you work and deciding what to change. Learn the formats, agenda, timings, and mistakes to avoid.

Retrospective timebox calculator

How long Keep, Problem, Try should run for your sprint length and team size, split across the five phases.

Icebreaker and check-in questions

Openers for the first two minutes of a Keep, Problem, Try session, sorted by situation.