Retrospective (team retro)
Look back at a finished piece of work, gather observations before discussing them, and leave with a small number of owned improvements.
- Time
- 45 min
- People
- 4–8
- Kind of work
- Understand · Scale
In short
A retrospective is a structured team meeting held after a sprint, project or event to review what happened and agree how to improve. To run it, set the period, let each person write observations silently first, group them into what worked and what did not, discuss the evidence, and choose two or three improvements with owners.
What it is
Retrospectives became widely known through agile software teams, who hold one at the end of each short cycle of work. The practice works just as well for a policy launch, an event, a busy season or a project of any kind. The aim is simple: learn from the period you have just finished while it is fresh, and carry one or two changes into the next one.
A good retrospective is about the work, not about blaming people. It looks at events, decisions and conditions, and treats everyone as having done their best with what they knew at the time. Writing observations silently before discussion matters, because it gives quieter people the same voice as confident ones and stops the first speaker setting the agenda.
When to use it
Use it when
- A sprint, project, launch or event has just ended.
- A busy season or incident is over and the team wants to learn from it.
- The same problems keep coming back and nobody has stopped to look at them.
- A new team has completed its first piece of work together.
- You want a regular habit of improvement, such as every two weeks or every month.
Skip it when
- Someone is under formal review; a retrospective is not a disciplinary process.
- The period is still running and people are too busy to reflect honestly.
- Leaders have already decided the outcome and will not act on what the team says.
You need
- Time
- 45 minutes for a two-week period; up to 90 minutes for a large project.
- People
- 4–8 people who did the work, plus a facilitator who was not central to it if possible.
- Materials
- A board with columns for worked, did not work and actions, sticky notes, a timeline of key events, and any useful data such as volumes or delays.
How to run it
Step 1: Set the scene
Name the period you are reviewing and remind everyone of the purpose: improve how we work, not judge who did what. Show a simple timeline of key events so everyone starts from the same picture.
Step 2: Collect observations silently
Give 8 minutes for each person to write observations, one per note, under worked and did not work. No discussion yet. Ask for facts and events, not people's names.
Step 3: Share and group
Each person reads their notes aloud and places them on the board. Group similar notes together and give each group a short label.
Step 4: Add evidence
For the larger groups, ask what we know about this. Add data, examples or dates beside the group. This keeps the discussion grounded and helps separate one bad day from a pattern.
Step 5: Choose what to work on
Give each person 3 dots to vote for the groups they most want to improve or protect. Pick the top two or three. Fewer actions that get done beat a long list that does not.
Step 6: Agree owned actions
For each chosen group, write one concrete action, an owner role and a date. Check each action is small enough to finish before the next retrospective.
Step 7: Close and follow up
Read the actions aloud. Ask each person for one word on how the session felt. Start the next retrospective by checking what happened to these actions.
Worked example
A government service centre had just finished a two-week extended-hours campaign to clear a backlog of residency renewals before a deadline.
Seven staff and a facilitator from another unit met two days after the campaign ended. The timeline showed the evening hours added each day and the final deadline.
In 8 silent minutes the group wrote 41 notes. Worked included the shared evening rota, the queue display and the quick-reference sheet for new rules.
Did not work included a document scanner at counter 4 that stopped twice in the busiest evening, and late changes to required documents that reached the counters by phone.
The team added evidence: the scanner fault log showed three failures in two weeks, and 120 applicants had been asked to come back because of the document change.
They chose three actions: the facilities lead would arrange a spare scanner before the next campaign, the supervisor would set up a single written channel for rule changes, and the shared rota would become the standard for future campaigns.
IllustrativeTips and mistakes
Tips
- Always write before talking; it is the single biggest improvement to most retros.
- Use a facilitator from outside the team for big or tense reviews.
- Keep what worked on the board; protecting good practice is also an action.
- Limit actions to two or three and check them at the next session.
- Vary the format now and then so regular retros stay fresh.
Common mistakes
- Turning the session into a search for who was at fault.
- Ending with a long list of actions that nobody owns.
- Skipping the check on last time's actions, so the same issues return.
- Letting the most senior person speak first and set the tone.
What you walk away with
You leave with a shared record of what worked and what did not, backed by evidence, and two or three owned improvements with dates. Use affinity grouping for larger sets of observations, or five whys to look deeper into a problem that keeps coming back.
Questions people ask
How long should a retrospective take?
About 45 minutes for a two-week period. A large project or major event may need 90 minutes. Shorter is fine if the team meets often.
What questions should a retrospective ask?
The core questions are what worked, what did not work, and what will we change. Some teams add what puzzled us or what we want to keep.
Retrospective vs post-incident review: what is the difference?
A retrospective reviews a normal period or project. A post-incident review looks at one specific failure in detail. Both should focus on the work and conditions rather than blame.
Tool card
The worksheet your team fills in, one box per field.
- Event
- Worked
- Did not work
- Evidence
- Action
- Owner