In short
Retrospective notes are worth keeping for one reason: to make sure the changes the team agreed to try actually get tried. So keep those, with an owner each and a way to tell whether they worked, and start the next retro by checking them.
The rest — the sticky notes, the votes, the discussion — can usually be thrown away.
This guide explains why most retro notes do not lead to change, gives a short template, shows a fictional example, and covers the notes' two awkward questions: what to do about sensitive discussion, and whether to record.
Why most retro notes change nothing
Retros often produce a lot of writing: a board of what went well, what did not, and ideas, followed by a list of actions. The board gets photographed, the actions get pasted into a document, and two weeks later the next retro starts with a fresh board. Nobody opens the old document.
Three patterns cause this:
- Too many actions. Ten improvements agreed in forty-five minutes is a wish list, not a plan.
- No owner. "We should review PRs faster" is agreed by everyone and owned by no one.
- No check. If nothing asks whether last time's change happened, there is no reason for it to.
Good retro notes fix all three by being short, owned and checked.
The template
# Retro — [team] — [sprint or period] — [date]
Facilitator: [name]
Notes: [name]
Present: [names]
## Last retro's changes
| Change | Owner | Did we do it? | Did it help? | Keep / drop / adjust |
| ------ | ----- | ------------- | ------------ | -------------------- |
| | | | | |
## Themes this time
- [theme, in a line] — [how many people raised it]
## Changes we agreed to try
| Change | Owner | How we'll know it worked | Check at |
| ------ | ----- | ------------------------ | ---------- |
| | | | next retro |
## Not now
- [ideas raised and deliberately parked]Last retro's changes
This goes first, before anyone writes a new sticky note. For each change: did we do it, did it help, and do we keep it, drop it or adjust it. It takes five minutes and is the section that makes the whole practice work. A change that keeps being carried over without being done should be dropped openly rather than carried again.
Themes this time
One line per theme, not every sticky note. The count of people who raised it is enough to show weight. If a theme was raised in the last retro too, say so; a theme that keeps coming back is telling you the change you made was the wrong one.
Changes we agreed to try
One to three. Each one needs:
- A concrete change, phrased as something someone does: "Tom books a 15-minute review slot each afternoon", not "improve code review".
- An owner, one person. They do not have to do all the work; they are the one who makes sure it happens and reports back. Writing meeting action items that get done goes into this in more detail.
- A sign it worked, something you could check in two weeks: "no PR waits more than a day for a first review".
- A check date, which is almost always the next retro.
Not now
Good ideas the team decided not to try this time. Writing them down lets people let go of them without feeling ignored, and gives the next retro something to pick from.
A fictional example
Harbour is an invented product; the team is invented too.
# Retro — Harbour — sprint 18 — 26 September 2026
Facilitator: Ana Ruiz
Notes: Marc Dubois
Present: Ana, Marc, Priya, Tom
## Last retro's changes
| Change | Owner | Did we do it? | Did it help? | Keep / drop / adjust |
| -------------------------------------------------- | ----- | ----------------- | ----------------------- | ------------------------------------------------ |
| Release notes drafted during the sprint, not after | Priya | Yes | Yes — released on day 1 | Keep |
| Pair on every migration | Tom | Twice out of four | Unclear | Adjust: pair on migrations touching billing only |
## Themes this time
- Reviews waiting too long before a first look — 3 people
- Standup running over — 2 people (also raised last retro)
## Changes we agreed to try
| Change | Owner | How we'll know it worked | Check at |
| ------------------------------------------------- | ----- | ---------------------------------------------- | ---------- |
| Daily 15-minute review slot, 14:00 | Tom | No PR waits more than a day for a first review | next retro |
| Standup: blockers and changes only; details after | Ana | Standup ends within 15 minutes on 8 of 10 days | next retro |
## Not now
- Rotating on-call for support ticketsNotice the standup change. The theme came back from the last retro, so the team changed the format rather than repeating "keep standup short". Standup meeting notes covers the format they moved to.
Keeping the discussion safe
A retrospective works when people can say what went wrong, including when it was their fault or a colleague's. Notes can undermine that if they are careless.
- Write themes, not attributions. "Reviews waited too long" rather than "Tom's reviews waited too long".
- Leave out the heated parts. The notes record what the team decided, not the argument that got there.
- Keep the audience to the team. If the notes go wider — to a manager or another team — agree that at the start, and write accordingly.
Whether to record a retro
Usually, do not. The value of a retro depends on candour, and a recording, even one kept only by the note-taker, can make people choose their words. The notes this guide describes are short enough to write live.
If a team wants a recording — a distributed team, someone who cannot attend — ask everyone before starting, agree who keeps it, and delete it once the notes are written. If one person is uncomfortable, do not record.
Retro notes from a recording with Notey
If your team has agreed to record, Notey records the call on the note-taker's Mac with nothing joining it, and transcribes it there. Its summary lists action items as who agreed to do what, and if nobody committed to anything it says so rather than inventing items — a useful check on whether the retro actually produced a change. The summary is labelled as AI-generated; compare it with what the team agreed before copying anything into the template. You can then delete the meeting, which removes its recording and transcript together.
For the general shape of meeting notes this template follows, see the meeting notes template. If some retro outcomes are really decisions — a new rule for how the team works — put them in the team's decision log too.
Checklist
- Start with last retro's changes: done, helped, keep, drop or adjust.
- Themes in a line each, not every sticky note.
- One to three changes, each with one owner and a sign it worked.
- Park the rest under "Not now".
- Themes, not blame, in the notes.
- Do not record unless everyone agrees.
Frequently asked questions
What should retrospective notes include?
The changes the team agreed to try, each with an owner and a way to tell whether it worked, plus a check on the changes from the last retro. The full list of what went well and badly is optional.
How many action items should come out of a retro?
One to three. A team that agrees to ten changes usually makes none of them; a team that agrees to one and checks it next time usually makes it.
Should you record a retrospective?
Usually not. A retro depends on people saying what went wrong, and a recording can make that harder. If the team wants one, ask everyone first, and agree who keeps it and when it is deleted.
Who should take notes in a retro?
Anyone except the facilitator, who is busy running the conversation. Rotate it, so the notes are not always written from one person's point of view.