It can be used after a sprint, campaign, project phase, event, launch, or recurring operational period. The output should be a tested change, not only a list of feelings.
Retrospective template at a glance
| Item | Recommendation |
|---|---|
| Review | One defined period, project, event, or outcome |
| Inputs | Metrics, customer evidence, incidents, and previous actions |
| Discussion | What went well, what did not, and contributing factors |
| Output | One or two improvement experiments with owners and dates |
| Follow-up | Review the result at the next retrospective |
Copyable Markdown retrospective template
# Retrospective: [Team, project, or period]
**Date:** YYYY-MM-DD
**Period reviewed:** [Start–end]
**Participants:** [Names or roles]
## Evidence reviewed
- Outcome or metric: [Result]
- Previous action status: [Summary]
## What went well
- [Specific practice or outcome worth repeating]
## What did not go well
- [Specific friction, failure, or missed expectation]
## What we learned
- [Learning supported by evidence]
## Themes and contributing factors
| Theme | Evidence | Contributing factor | Within our control? |
|---|---|---|---|
| [Theme] | [Example] | [Cause or condition] | Yes/Partly/No |
## Improvement experiments
| Experiment | Expected result | Measure | Owner | Review date |
|---|---|---|---|---|
| [Small change] | [Expected effect] | [Signal] | [Name] | YYYY-MM-DD |
## Actions
- [ ] [Action] · **Owner:** [Name] · **Due:** YYYY-MM-DD
What should a retrospective include?
A useful retrospective includes:
- the exact period or outcome being reviewed;
- evidence, including metrics and previous actions;
- specific examples of what helped and what hindered;
- contributing factors rather than blame;
- one or two changes small enough to try;
- an owner, measure, and review date for each change.
The familiar “what went well, what did not, what should change” structure is effective because it is easy to understand. The quality depends on the evidence and follow-through.
How to run the retrospective
Establish the review boundary
Name the sprint, campaign, quarter, project phase, or incident. A discussion about “everything lately” becomes difficult to act on.
Review previous actions
Start with the experiments agreed last time. Check whether they happened and whether the expected result appeared.
Gather input before discussion
Give participants quiet time to write observations. This helps prevent the first speaker from defining the entire conversation.
Group observations into themes
Combine similar entries, then discuss the themes with the strongest impact or evidence. Do not spend equal time on every note.
Turn learning into an experiment
“Communicate better” is not an experiment. “For the next two weeks, publish scope changes in the project channel within one hour, then measure missed handoffs” can be tested.
Completed retrospective example
## What did not go well
- Three final-review requests arrived after the agreed deadline.
## Contributing factor
- The review date was in the project plan but not in the reviewers' calendars.
## Improvement experiment
| Experiment | Expected result | Measure | Owner | Review date |
|---|---|---|---|---|
| Send calendar holds when the plan is approved | Fewer late reviews | Late review count | Noor | 2026-10-30 |
The action changes a specific condition and defines how the team will know whether it helped.
Retrospective versus lessons-learned report
A retrospective is a collaborative reflection and improvement process. A lessons-learned report is often the durable record shared beyond the immediate team.
For a major project, run the retrospective first. Then publish the verified lessons, evidence, and recommendations in the organization’s knowledge system.
Create psychological safety without removing accountability
Discuss systems, choices, and observable events. Avoid using the document to shame individuals.
Blameless does not mean consequence-free. It means the team examines how the environment, information, incentives, and decisions contributed to the outcome so it can design a stronger process.
Sensitive personnel matters should follow the appropriate private process instead of being recorded in a broadly shared retrospective.
Common retrospective mistakes
- Relying on memory while ignoring metrics or previous actions.
- Listing vague positives and negatives without examples.
- Jumping to solutions before understanding contributing factors.
- Creating five or ten actions that the team cannot absorb.
- Assigning actions to “the team” rather than one owner.
- Never reviewing whether the change worked.
- Using the meeting for blame or performance management.
Retrospective FAQ
What are the three main retrospective questions?
What went well? What did not go well? What will we change? Add evidence and action ownership so the answers lead to improvement.
How long should a retrospective take?
Thirty to sixty minutes is enough for many teams. Complex projects or incidents may require more time and separate analysis.
How many actions should a retrospective create?
Usually one or two measurable experiments. A smaller list increases the chance that the team will complete and review them.
Is a retrospective only for Agile teams?
No. Any team can review a campaign, event, operational period, project phase, or recurring process.
What if the same problem appears every time?
Check whether the previous action happened, whether it addressed the actual contributing factor, and whether the team had authority to make the change. Escalate structural constraints instead of repeating the same note.
Related templates
- Project plan template
- Release notes and changelog template
- Decision log template
- Risk register template
- All Markdown templates