Retrospective Template
What went well, what did not, and the three things you will actually change.
Details
retrospective templateUploads
Your logo
A photo or picture
Goes on this page only. Drag it anywhere and pull its corner to resize it.
Your signature
Draw it with a finger, a mouse or a trackpad, and it goes on the page like a picture.
Pictures and signatures stay on this device. Nothing is uploaded to a server.
Red highlights mark what is still blank. Click anything on the page to change it. Your draft is kept on this device as you work.
| Reviewing | [what period or piece of work] |
| Held on | October 14, 2026 |
1. What went well
[add one per line]
2. What did not
[add one per line — the process, not the person]
3. What we will try
[add one per line]
4. Actions
| Action | Owner | By when |
|---|---|---|
| [add one action per line] |
Actions without an owner and a date are opinions. Anything left here unowned should be struck out rather than carried forward.
What is a Retrospective?
A retrospective is the written record of a team looking back at a finished sprint, project, launch or incident and deciding what to keep, what to stop and what to change. Without it the discussion still happens, everyone nods, and nothing moves: the next project hits the same supplier delay and the same late sign-off. The document exists to convert an hour of talking into three named, dated commitments someone will be asked about.
Delivery teams run retrospectives at the end of a sprint or a release, but the format travels further than software. Agencies use one after a campaign ships, event teams after the venue is cleared, operations teams after an outage, construction and manufacturing teams at the close of a phase, and schools after an admissions cycle. It also works for a team of one: a freelancer reviewing a difficult client engagement gets the same benefit, which is a written reason not to accept the same terms again.
The retrospective itself is not regulated, but what you write in it can be. Notes that name individuals are personal data under the UK and EU GDPR and under comparable regimes elsewhere, so the record is disclosable to the person named on request — check your organisation's retention rule before writing anything you would not repeat to their face. In regulated sectors a review may also be compulsory rather than optional: healthcare incident reporting, financial services operational resilience requirements and workplace safety investigation duties all have their own forms and deadlines. Confirm which applies before treating the retrospective as the record.
A retrospective is not a performance review. It looks at the system that produced the result — handovers, estimates, approvals, tooling — and the moment it turns into a list of who underperformed, people stop telling the truth in it and the document loses its only value. Nor is it a root cause analysis for a regulator or insurer, which needs evidence, a defined timeline and a stated methodology. And it is not a status report: it says nothing about where the work stands now, only about how it went.
What to put in a Retrospective
These are the details this template asks for. Anything left blank is marked in red on the preview so you can see what is still missing.
| Field | What goes in it |
|---|---|
| Issuing organisation | For example: Maple Grove Homeowners Association |
| Organisation address | For example: 1420 Kinnear Road, Columbus, OH 43212 |
| What is being reviewed | For example: Barton Road fit-out — weeks 1 to 6 |
| What went well | One per line |
| What did not | One per line |
| What we will try | One per line |
| Actions | One per line: Action | Owner | By when |
How to write a Retrospective
Fix the scope and the time window
Write at the top exactly what is being reviewed and over what period: sprint 14, the fortnight ending at release, or the Henderson launch from kickoff to go-live. Without a boundary the session drifts into old grievances nobody can act on. If something important sits outside the window, log it as a separate item rather than letting it swallow the hour you have.
Collect the facts before the opinions
Put the observable record on the page first: dates work was promised and delivered, the number of defects reopened, the days spent waiting on a decision, the two changes of scope. People argue about impressions and agree about a timeline. Circulating the facts a day early also lets the quieter members of the team arrive with something written rather than being talked over.
Separate what helped from what hurt
Two columns, not one. The things that went well are worth writing down because they are the practices you would otherwise quietly drop under pressure — the daily fifteen-minute triage, the single point of contact at the client. The things that hurt should be written as events, not adjectives. “Communication was poor” is unusable. “The test environment was unavailable for four working days” is something you can fix.
Choose three changes and name owners
Three is the number a team actually delivers. For each one write the change, the person who owns it, and the date by which it will have happened — not the date it will be discussed. Move the review meeting to Tuesday morning, owned by Priya, in place from next sprint. Ten improvement ideas with no owner is the commonest way a retrospective produces nothing at all.
Circulate it and reopen it next time
Send the finished page to everyone who was in the room and to whoever has to approve the changes. Then open the next retrospective with it: read the three commitments aloud and mark each done, dropped or still running. That thirty-second ritual is what stops the document becoming decorative, because people know they will be asked in front of the team.
Common mistakes
- Running the session without a written record, so the agreements exist only in memory and the next project repeats the same delay.
- Listing every irritation instead of picking three, which spreads effort so thin that none of the changes is finished before the following retrospective.
- Assigning an action to a team rather than a person, which reliably means nobody starts it.
- Letting the most senior person speak first, after which the room converges on their version and the useful disagreement never surfaces.
- Naming individuals as the cause of failures, which teaches everyone present to withhold the next problem until it is too big to hide.
Frequently asked questions
What should a retrospective include?
A scope line saying what period is under review, the facts as they happened, what went well, what did not, and three changes with an owner and a date against each. Anything else is optional. The two sections people skip — the scope line and the owner column — are the two that decide whether the document is usable a month later.
What is the difference between a retrospective and a post-mortem?
In common use a retrospective is scheduled and looks at how a team worked over a period, while a post-mortem or incident review is triggered by a specific failure and digs into its causes. The retrospective asks what to change about the way we work; the incident review asks what happened and why. Some organisations use the words interchangeably — agree yours before the invitation goes out.
Who should attend a retrospective?
Everyone who did the work, and nobody whose presence stops them speaking. That usually means the delivery team plus whoever coordinated it, and not the client or the skip-level manager. If a senior stakeholder needs to hear the outcome, send them the document rather than seating them in the room; you will get a more honest page and they will get a shorter one.
How long should a retrospective take?
An hour suits a two-week sprint and is about as long as most teams hold attention. A quarter or a whole project justifies longer, and a small fix does not need a meeting at all. What really decides the length is preparation: if the facts are circulated beforehand, the hour goes on deciding what to change instead of reconstructing what happened.
How do you run a retrospective after a project went badly?
Write the timeline first and circulate it before anyone meets, so the session starts from an agreed sequence of events rather than competing accounts. Keep the language on decisions and conditions rather than people. If the failure carries a contractual, safety or regulatory consequence, speak to your legal or compliance contact before the notes are written — what you record may be disclosable later.
This page explains general practice and is not legal advice. Requirements differ between countries and, in some cases, between states — check what applies where the document will be used.