Free Retrospective Meeting Agenda Template
A blameless retrospective agenda that turns into real improvements, not just venting.
Part of our free meeting agenda templates.
Your download has started.
Didn’t start? Retry the Word file or get the PDF.
1.Meeting Information
| Date | {{Date}} |
|---|---|
| Time | {{Start – End time}} |
| Location | {{Location or video link}} |
| Facilitator | {{Facilitator}} |
| Note-taker | {{Note-taker}} |
| Attendees | {{Attendees / required vs optional}} |
Fill this block before you send the invite so everyone knows when, where, and who is expected. Name a facilitator and a note-taker — meetings without both tend to drift.
2.Objectives
- Reflect honestly and blamelessly on the last {{sprint / period}}
- Surface what to keep doing, stop doing, and start doing
- Commit to {{1–3}} concrete improvements with an owner each
State one to three outcomes this meeting must produce — a decision, a plan, an aligned team. If you cannot name an objective, the meeting can probably be an email.
3.Agenda
| Topic | Lead | Time | Type |
|---|---|---|---|
| Set the stage & ground rules (blameless, everyone speaks) | {{Facilitator}} | 5 min | Inform |
| Review action items from the last retro | {{Facilitator}} | 5 min | Inform |
| What went well | All | 10 min | Discuss |
| What didn’t go well | All | 10 min | Discuss |
| Discuss themes & root causes | All | 15 min | Discuss |
| Agree improvements: keep / stop / start | All | 10 min | Decide |
| Assign owners & a check-in date | {{Facilitator}} | 5 min | Decide |
Give every item an owner, a time box, and a type — Inform, Discuss, or Decide — so people come prepared and you protect time for the decisions that matter. Put the most important item first, not last.
4.Decisions & Notes
| Topic | Decision / key note | Follow-up |
|---|---|---|
| {{Theme}} | {{Improvement the team agreed to try}} | {{How we’ll check it worked}} |
Capture decisions as they happen, in the room. A one-line record of what was decided prevents the same debate from reopening next week.
5.Action Items
| Action | Owner | Due date |
|---|---|---|
| {{Improvement — start with a verb}} | {{Owner}} | {{By next retro}} |
| {{Action}} | {{Owner}} | {{Due date}} |
Every action needs a single owner and a date — “we” is not an owner. Read these back aloud before you close the meeting so nobody leaves surprised.
6.Parking Lot
- {{Bigger issue that needs its own conversation}}
Park anything important that is off-agenda here instead of letting it derail the meeting. Review the parking lot when you plan the next agenda.
7.Next Meeting
| Date & time | {{Date and time}} |
|---|---|
| Focus | {{Main focus for next time}} |
Set the next meeting before everyone leaves — it is far harder to schedule afterward. Note the main focus so the next agenda almost writes itself.
A worked example for a software squad’s end-of-sprint retrospective.
1.Meeting Information
| Date | Friday, June 19, 2026 |
|---|---|
| Time | 3:00 – 4:00 PM |
| Location | Team room + Miro board for remote members |
| Facilitator | Aisha Khan, Engineering Manager (rotating) |
| Note-taker | Captured live on the Miro board |
| Attendees | Payments squad (6 engineers), PM Lena Voss, QA lead Sam Park |
2.Objectives
- Reflect blamelessly on Sprint 24, which included the Apple Pay rollout
- Find out why the staging environment kept blocking us
- Commit to two improvements we can actually finish next sprint
3.Agenda
| Topic | Lead | Time | Type |
|---|---|---|---|
| Set the stage: blameless, focus on the system not people | Aisha Khan | 5 min | Inform |
| Action items from Sprint 23 retro — did they land? | Aisha Khan | 5 min | Inform |
| What went well | All | 10 min | Discuss |
| What didn’t go well | All | 10 min | Discuss |
| Theme deep-dive: staging flakiness & late QA handoffs | All | 15 min | Discuss |
| Agree keep / stop / start improvements | All | 10 min | Decide |
| Owners & check-in at mid-sprint | Aisha Khan | 5 min | Decide |
4.Decisions & Notes
| Topic | Decision / key note | Follow-up |
|---|---|---|
| Staging flakiness | Stop sharing one staging env across squads; spin up an ephemeral env per PR | Marco to spike the ephemeral-env setup and report mid-sprint |
| Late QA handoffs | Start bringing QA into refinement so tests are ready before code is done | Sam joins refinement from Sprint 25 |
| Apple Pay rollout | Keep the feature-flag + dashboard-alert pattern — it made the launch calm | Document it as the team’s rollout playbook |
5.Action Items
| Action | Owner | Due date |
|---|---|---|
| Spike ephemeral per-PR staging environments and share findings | Marco Diaz | Wed Jun 24 (mid-sprint) |
| Add QA to sprint refinement and write test cases earlier | Sam Park | Sprint 25 refinement |
| Write the feature-flag rollout pattern into the team playbook | Priya Sharma | Fri Jun 26 |
| Reduce WIP: cap in-progress stories at four next sprint | Lena Voss | Sprint 25 planning |
6.Parking Lot
- On-call load is uneven across the squad — bring to the next 1:1s
- Whether to split the squad as the payments scope grows — leadership topic
7.Next Meeting
| Date & time | Friday, July 3, 2026 · 3:00 PM |
|---|---|
| Focus | Sprint 25 retrospective — did ephemeral envs and earlier QA help? |
How it works
- Set the stage and review last retro’s action items to open the meeting.
- Gather what went well and what didn’t, then discuss themes and root causes.
- Agree a few keep/stop/start improvements with an owner each, then download as Word or PDF.
Frequently asked questions
What should a retrospective agenda include?
A good retrospective sets the stage with a blameless tone, reviews the previous retro’s actions, gathers what went well and what didn’t, digs into themes and root causes, and ends by agreeing a few concrete improvements (keep / stop / start) with an owner and a check-in date. This template lays out exactly that flow.
What are the questions to ask in a retrospective?
The classic three are: What went well? What didn’t go well? What will we do differently? Variations include “Start, Stop, Continue” and “Mad, Sad, Glad.” The goal is honest reflection that leads to a small number of real, owned improvements — not a long list nobody acts on.
How do you run a blameless retrospective?
Set the ground rule that the goal is to improve the system, not blame people, and remind everyone that each person did their best with what they knew. Focus on processes and conditions, give quieter voices room, and keep the discussion specific. A blameless tone is what makes people raise the real problems.
What is the difference between a retrospective and a post-mortem?
A retrospective is a regular, forward-looking team habit — usually at the end of each sprint or project phase — to keep improving. A post-mortem (or incident review) is a deeper, one-time analysis after a specific failure or incident. Both should be blameless and end with owned actions.