Retrospective Notes Template
A retrospective notes template that ends in action: last retro’s actions, what went well, what didn’t, ideas, and two or three changes with an owner each. Free to download in Word or PDF, no sign-up, with a filled-in sprint retro example.
Free. No sign-up.
Dalm is a Mac app that records a meeting — a call or a room — and drafts notes from the transcript. Get early access
Retrospective notes are worth keeping for one reason: the action plan. What went well and what didn’t is context; the point is the two or three changes the team commits to, each with an owner, a start and a way to tell whether it worked. That is why the template opens with the actions from the last retro. If nobody checks them, the next retro produces the same complaints and a fresh list nobody follows, and the team stops believing the meeting changes anything.
What’s in the template
The file follows a retro from last time’s promises to this time’s:
- Header — team, period or sprint, facilitator and attendees.
- Actions from the last retro — a table: action, owner, and done? what changed?
- What went well — a list.
- What didn’t go well — a table: problem and its cause, if someone named it.
- Ideas — a list.
- Action plan — a table: change we’ll make, owner, starting when, and how we’ll know it worked.
The template opens with one line on its purpose: notes from a team retrospective — what went well, what didn’t, and a short list of changes the team commits to, each with an owner; the action plan is the point, the rest is context.
Sprint retrospective example
Example (fictional). Names and events are invented.
| Team | Mobile app |
| Sprint | No. 21, |
| Facilitator | Marina |
| Attendees | Six team members |
Actions from the last retro
| Action | Owner | Done? |
|---|---|---|
| Show the demo inside the team a day early | Whole team | Yes — demo had no surprises |
What went well
- Sprint goal reached despite late requirements.
- Working on mock data kept the integration moving.
What didn’t go well
| Problem | Cause |
|---|---|
| Role requirements arrived on day 4; estimates had to be redone | Item entered the sprint without ready requirements |
| Testing stopped for two days | Only one tester, who was out sick |
Ideas
- Rotate a developer into testing each sprint (not chosen this time).
Action plan
| Change | Owner | From | How we’ll know |
|---|---|---|---|
| No item enters a sprint without ready requirements | Whole team | Next sprint | No re-estimation mid-sprint |
| Agree testing backup with the neighbouring team | Ilya | not set | No testing gaps over one day |
Two things here are worth copying. Each problem is written as a fact about the process — an item entered without requirements, a team had one tester — so nobody has to defend themselves. And each action carries its own test: “no re-estimation mid-sprint” is something the next retro can check in a minute, which is what turns a change into something more than a good intention.
How to fill it in
A retro is only as good as what happens after it. The five rules in the template protect that: open with last time’s actions, talk about the process rather than the people, commit to a few small changes instead of a long list, give every change an owner, and keep the ideas you set aside so they are there when the team is ready for them.
- Start with last retro’s actions. If they’re never checked, retros stop mattering.
- No names next to criticism if the team asked for that. Describe the process, not the person.
- 2–3 actions, not ten. Small changes the team will actually make.
- Every action gets an owner. “Whole team” is fine only for a team rule.
- Keep rejected ideas under “Ideas” — they’re useful next time.
From retro to real change
Write every action so the next retro can check it: a change, an owner, a start and a sign that it worked. “Communicate better” cannot be checked; “no item enters a sprint without ready requirements, starting next sprint, and we’ll know because nothing is re-estimated mid-sprint” can. Then make the check the first item of the next retro, before anyone says what went well. Go through the actions one by one: done or not, and what changed. A change that worked becomes part of how the team works and leaves the list. One that did not is either reworked with a smaller step or dropped on purpose — not left to fade. Only then add the new actions.
Retro or another team meeting
| You need | Use |
|---|---|
| What the team learned from a sprint and the changes it commits to | This retrospective notes template |
| What the team takes into the next sprint: goal, backlog, capacity | Sprint planning notes template |
| A daily check-in: yesterday, today, blockers | Daily standup notes template |
| A weekly working record for a team or department | Staff meeting minutes template |
| Why an incident happened and what stops it happening again | Root cause analysis report template |
Every other template is on the templates page.
If you would rather not take notes at all
You can fill in this template by hand. If you would rather take part in the retro, Dalm is a Mac app that records the meeting — a call, or a conversation in the room through the Mac’s microphone — and drafts notes from the transcript to start from. The draft is its own document rather than this template filled in: you correct it line by line and save it as PDF, Word (.docx) or Markdown.
See plans · For teams
Questions
- What should you write down in a retrospective?
- Start with the actions from the last retro and whether they changed anything. Then what went well, what did not — with the cause if someone named it — and the ideas raised. The part that matters most is the action plan: two or three changes, each with an owner, a start and a way to tell whether it worked.
- How many action items should a retro have?
- Two or three. A list of ten looks thorough and rarely gets done; a short list of small changes the team will actually make is easier to own and easier to check at the next retro. Good ideas that did not make the cut stay under Ideas for next time.
- Should retro notes include names?
- That is the team's call, and it is worth agreeing up front. Many teams leave names out next to criticism and describe the process instead of the person — "the item entered the sprint without ready requirements" rather than who let it in. Owners of actions are named either way, because an action without an owner does not happen.
- How do you follow up on retro actions?
- Open the next retro with them. For each action, say whether it was done and what changed, using the measure written next to it when it was agreed. Actions that worked become how the team works; ones that did not are dropped or reworked — but each gets an answer before anything new is added.
- Is the template free?
- Yes. The Word and PDF files download free, with no account and no e-mail address asked. The template is in English and carries no product name or branding, so you can rename the sections to match your retro format and reuse it every sprint.