Keep Problem Try
A compact Japanese-inspired format: anchor strengths, name problems, pick tries.
Keep
Good practices and outcomes to sustain.
Problem
Issues, pain points, or friction to address honestly.
Try
Small experiments or changes you will attempt next.
This board is for demo purposes only. Your responses are not saved. Close or refresh the page to clear all cards. Do not add any sensitive information.
What is Keep Problem Try?
Keep Problem Try, commonly abbreviated as KPT, is a retrospective format that originated in Japanese manufacturing and software development communities. It draws heavily from the kaizen philosophy of continuous improvement that underpins the Toyota Production System. The format was adapted for agile software teams in Japan during the early 2000s and has since spread globally through agile coaching networks and conference presentations.
The three columns are elegantly simple. "Keep" identifies practices and behaviors that are working well and should be preserved. "Problem" names specific issues, pain points, or inefficiencies that need attention. "Try" proposes small experiments or changes the team will attempt in the next iteration. The deliberate use of "Try" instead of "Action Item" or "Fix" reflects the kaizen mindset—improvements are experiments to be validated, not mandates to be enforced.
KPT is distinguished from similar formats by its emphasis on experimentation over commitment. The "Try" column explicitly frames changes as hypotheses rather than permanent decisions. This lowers the psychological barrier to proposing changes because a failed experiment is learning, not failure. Teams that use KPT consistently tend to develop stronger experimentation cultures over time.
When to use Keep Problem Try
KPT is ideal as a regular sprint retrospective format for teams that value simplicity and experimentation. Its compact three-column structure makes it fast to facilitate—most teams complete a productive KPT session in 30 to 45 minutes, making it practical for teams with tight schedules or those who find longer retros draining.
The format works well for teams of three to eight people and is particularly effective for teams practicing Lean or Kanban alongside Scrum. Its roots in Japanese continuous improvement philosophy align naturally with flow-based approaches. It is also excellent for teams that suffer from action item overload—the experimental framing of "Try" naturally limits scope to small, testable changes.
Use KPT when your team is disciplined and prefers concise formats over elaborate ones. Avoid it when the team needs to process emotions or when complex issues require more columns to decompose. KPT works best as a frequent, lightweight touchpoint rather than a deep quarterly review. If your problems are systemic and interconnected, consider a more expansive format that allows for root cause exploration.
How to facilitate Keep Problem Try
Begin by reviewing the "Try" items from the previous retro. For each one, ask: "Did we try it? What happened?" This accountability loop is the most important part of KPT and what makes it effective over time. Categorize previous tries as "adopted into Keep," "still experimenting," or "abandoned with learning." This takes five to eight minutes and sets a serious tone for the new session.
Give the team five minutes of silent writing for Keep and Problem columns simultaneously. Process Keep first—briefly celebrate and acknowledge what is working. Then process Problem items, grouping related issues and dot-voting to identify the top two or three. For each prioritized problem, facilitate a brief discussion: "What is causing this? What could we try differently?"
The Try column is populated during discussion rather than during silent writing. As the team discusses problems, capture proposed experiments directly in the Try column. Each Try should follow the format: "We will try X to see if it improves Y." Limit tries to two or three per retro. Close by reading each Try aloud and confirming that everyone understands what will be different in the next sprint.
Tips for getting the most out of Keep Problem Try
The most common failure mode is treating "Try" as "Fix." When someone proposes a large initiative as a try—like "try rebuilding the CI pipeline"—help them break it into a smaller experiment: "try adding a build cache for the slowest test suite to see if it cuts CI time by 30 percent." Small tries are faster to validate and less risky to abandon.
Another key insight: the "Keep" column is not just a feel-good exercise. It serves as the team memory of what works. Over multiple retros, the Keep list becomes a living document of team best practices. Some teams maintain a running "Keep" list that new members read during onboarding. This institutional knowledge transfer is one of KPT most underrated benefits.
Track tries across sprints using a simple spreadsheet or board. Each try should have a status: "in progress," "adopted," or "abandoned." If a try is abandoned, record why. This try-tracking habit turns your retrospectives into a formal experimentation system that compounds improvement over time. Teams that track tries rigorously for six months typically report significantly faster improvement cycles than those using ad hoc action items.
Variations and adaptations
For remote teams, the simplicity of KPT makes it one of the easiest formats to run asynchronously. Share a three-column board and give the team 24 hours to populate Keep and Problem. Then hold a brief 20-minute synchronous session focused on discussing problems and generating tries. The compact format works well even in a 30-minute remote call because it does not require extensive reading or grouping.
For larger teams, run KPT in parallel small groups of three to four people, then merge the results. Each group identifies their top problem and proposes one try. The merged session reviews all proposed tries and selects the most impactful two or three for the whole team. This scaling approach preserves the intimacy needed for honest problem identification while enabling coordination across a larger group.
A popular variation in Japanese agile teams adds a "Problem-Try" linking step where each try must explicitly reference which problem it addresses. This prevents orphan tries—experiments that seem interesting but do not connect to a named problem. Another adaptation adds a "Learn" column between Problem and Try to capture insights about why problems exist before jumping to solutions. This slows the process slightly but produces better-targeted experiments.
Run Retrospectives in CodeKudu
CodeKudu includes dozens of retrospective board templates, anonymous feedback, AI summaries, and action items that sync to GitHub Issues, Jira, and Linear.