Retrospective Meeting Notes Template

A retrospective is only as good as its shortest section

Every retrospective format, whatever its theme, reduces to three questions: what helped, what hurt, and what will we change. Teams don't abandon retrospectives because the questions are wrong — they abandon them because the third section keeps failing. The actions list grows to nine items, none of them owned, none of them reviewed next time, and within a quarter the retro is a ritual complaint session with sticky notes.

So this template enforces two disciplines. First, the actions section is capped at three items, each with one owner and a date — if a fourth action matters, it displaces one of the three, it doesn't join them. Second, the notes open with the previous retro's actions and their status, before any new discussion. A retro that never checks whether last time's fix worked is asking the team to believe in a process that visibly doesn't. Copy the template, keep one running doc per team, and let the format do the enforcement.

The retrospective meeting notes template (copy and paste)

# Retrospective — [Team name] — [Sprint / period] — [Date]

**Facilitator:**
**Attendees:**

## Last retro's actions — review
| Action | Owner | Status |
|--------|-------|--------|
|        |       | Done / In progress / Dropped (and why) |

## What went well
-

## What didn't go well
-

## Root causes / patterns (not just incidents)
-

## Actions (maximum 3)
| # | Action | Owner | By when | How we'll know it worked |
|---|--------|-------|---------|--------------------------|
| 1 |        |       |                          |                          |
| 2 |        |       |                          |                          |
| 3 |        |       |                          |                          |

## Appreciations
-

Example: a filled sprint retrospective

A six-person team at the end of a two-week sprint in which the release slipped by three days. Note that "what didn't" names process facts, not people — and that the root-cause section earns its place by connecting two incidents that looked unrelated.

# Retrospective — Checkout Team — Sprint 14 — Fri Oct 24

**Facilitator:** Yusuf (rotating)
**Attendees:** Full team (6), plus Marta from data

## Last retro's actions — review
| Action | Owner | Status |
|--------|-------|--------|
| Add contract tests for the payments API | Priya | Done — caught 2 breaking changes this sprint |
| No-meeting Wednesday mornings for build focus | Yusuf | In progress — held 1 of 2 weeks; launch reviews overran |
| Write the release checklist before code freeze | Tom | Dropped — release consumed the time it was meant to organize; rewritten as action 1 below |

## What went well
- Contract tests paid off immediately: the payments API changed a
  field name mid-sprint and CI caught it before staging did.
- Pairing on the error-state work — Elena and Sam cleared in two days
  what was estimated at four, and the knowledge is now shared.
- Support was looped in before launch day, not after; Chris had the
  help docs ready when the first tickets arrived.

## What didn't go well
- Release slipped 3 days. The slip was discovered on the last day of
  the sprint, not during it — status looked green until integration.
- CI was flaky for two full days (payment test fixture again);
  people stopped trusting red builds and started re-running instead
  of reading failures.
- The release checklist action from last retro was dropped because
  the release itself ate the time — the fix for release chaos keeps
  being postponed by release chaos.

## Root causes / patterns (not just incidents)
- "Green until integration" is a pattern, not bad luck: this is the
  second sprint where work was individually done but jointly late.
  The team has no mid-sprint integration point, so integration risk
  concentrates on the final day.
- Flaky CI is being treated as weather — something to endure — rather
  than as a defect with an owner. Every re-run teaches the team to
  ignore the next real failure.

## Actions (maximum 3)
| # | Action | Owner | By when | How we'll know it worked |
|---|--------|-------|---------|--------------------------|
| 1 | Write the release checklist this week, before Sprint 15 planning, and run the next release strictly from it | Tom | Oct 29 | Next release follows the checklist; retro reviews the result |
| 2 | Add a mid-sprint integration checkpoint (day 5): all features merged to staging, smoke test together | Yusuf | Sprint 15, day 5 | Integration issues surface by day 5, not day 10 |
| 3 | Fix or quarantine the flaky payment fixture; flaky tests get an owner and a one-sprint deadline from now on | Sam | Nov 5 | CI re-run rate drops; measured from CI logs |

## Appreciations
- Priya, for the contract tests that quietly saved the release.
- Chris, for having support docs ready before anyone asked.

Two details to copy. The dropped action from last time wasn't buried — it was reviewed, explained, and re-issued as this retro's first action with a nearer date; dropped actions that get honestly re-committed are how a team learns the process works. And each new action has a "how we'll know it worked" column, so the next retro reviews effects, not just completion.

Running a retro people don't dread

• Blameless is a rule about language, not a vibe. Notes describe what the process allowed to happen: "the release had no checklist" is actionable; "Tom forgot the checklist" is a verdict. Write every "didn't go well" item so it would be fair to read aloud with the whole team — and any other team — in the room.
• Incidents are data; patterns are the agenda. One late delivery is an incident. "Integration risk lands on the last day" is a pattern. Push the discussion one level down — why did the system produce this outcome? — or the retro fixes symptoms every fortnight forever.
• Anonymous input helps, then hurts. Anonymous sticky notes are a good way to surface sensitive items in a new or low-trust team. But if everything is still anonymous after six months, the retro has found its real problem, and it isn't the build pipeline.
• Alternate the lens occasionally. The well/didn't/actions format is the workhorse, but a start/stop/continue or a timeline retro ("walk the sprint day by day") once a quarter surfaces things the standard format has gone blind to.
• End with appreciations, specifically. Not "great job everyone" — one named person, one concrete thing. It costs ninety seconds and it is the part of the retro people actually remember on a bad day.

How an AI note taker helps with retrospectives

Retros are spoken, fast, and multi-voice — exactly the meeting where the note taker misses who raised what, or softens a sharp point into a vague one. With CoHear, the retro is recorded on an iPhone in the room — no bot joins, which matters in a meeting whose honesty depends on it feeling like a closed room — and the transcript preserves each point as it was actually said, as verbatim quotes with timestamps. The organized summary arrives in about 65 seconds for an hour-long retro, sorted into the same shape as the template: positives, problems, and candidate actions.

That fidelity cuts both ways, so use it deliberately: the point of recording a retro is a shared, accurate record of what the team itself concluded — the actions, the patterns, the appreciations — not a transcript circulated to management. Keep the retro doc (this template, filled) as the artifact that leaves the room; use the recording to write it faithfully, then let the team's privacy defaults do the rest. Review the actions section together before closing, the same as any AI-drafted notes.

Retros usually sit at the end of a cycle that starts with a project kickoff and runs on the weekly team meeting notes template. For other formats, see the general meeting notes template.

More templates

• All note-taking templates