KPT Retrospectives: A Practical Guide with a Filled Template
Published:
Last Updated:
KPT is a retrospective format built around Keep, Problem, and Try. Keep captures useful practices, Problem records obstacles and their effects, and Try turns learning into an experiment for the next cycle. It works well when a team needs a compact structure for discussing a release, campaign, or Sprint.
The agenda, people, and figures below are illustrative examples, not reported customer results.
Separate observations from actions
Column | What to capture | Example |
|---|---|---|
Keep | An action worth repeating and why | A second person checked tracking before launch and found a missing tag |
Problem | An observable event and its impact | The draft waited two days because the approver was unclear |
Try | A specific experiment | Name an approver and backup before drafting begins |
“Communication was poor” does not identify a change the team can make. Describe which handoff failed and what happened next. Likewise, “we worked hard” is less reusable than a concrete practice that helped.
KPT is one possible format for a retrospective. In Scrum, the purpose of the Sprint Retrospective is to improve quality and effectiveness; KPT itself is not mandatory. See Scrum.org’s explanation.
A practical 45-minute agenda
- Spend five minutes on the period, its goal, and the previous Try actions.
- Give everyone seven quiet minutes to write Keep and Problem notes independently.
- Use ten minutes to group related notes and clarify facts.
- Spend eight minutes choosing issues by future impact and the team’s ability to influence them.
- Use ten minutes to design one or two experiments, then five minutes to confirm owners and review dates.
Treat this as a starting agenda. A major incident may need a separate investigation. Producing more notes is not the objective; changing a useful part of the work is.
A filled action template
Field | Illustrative entry |
|---|---|
Period and goal | Sprint 3: test the application journey |
Keep | Agree acceptance criteria before starting |
Problem and effect | Approval took two days and delayed testing |
Try | Name an approver and backup; include a response deadline |
Owner and due date | Campaign owner A; next cycle’s first day |
Review | Compare approval waiting time and rework at the next retrospective |
Decision | Continue, adjust, or stop, with a reason |
Completing the action and validating its effect are different steps. Faster approval is not sufficient evidence of success if rework increases. Check the quality of the handoff as well as the time it takes.
Fix common failure patterns
If the same problem returns, first ask whether the previous experiment happened. An untried action needs an owner or capacity; an ineffective action needs a revised hypothesis. These are different problems.
If participation is low, allow advance or anonymous input and explain who will see the notes. Keep the discussion focused on work practices rather than individual appraisal. Replace vague actions such as “be more careful” with observable changes, such as adding a tracking verification field to the launch checklist.
A Try can also extend a Keep practice to another workflow. Improvement includes repeating what helped, not only removing what failed.
Choose a format and follow through
Use KPT for a concise discussion of observations and next actions. For alternative ways to explore learning and team experience, read Retrospective Frameworks. For the broader framework, read The Scrum Framework.
After the meeting, place the chosen action into the actual work plan and review its effect next time. Xtrategy’s project management features connect campaign task progress, costs, and approval information. Explore them when you want retrospective actions to remain connected to day-to-day campaign work.
