Free Retrospective Meeting Agenda Template

A blameless retrospective agenda that turns into real improvements, not just venting.

Part of our free meeting agenda templates.

Download Word (.docx)

Download PDF Free · No signup · No watermark

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

TopicLeadTimeType
Set the stage & ground rules (blameless, everyone speaks){{Facilitator}}5 minInform
Review action items from the last retro{{Facilitator}}5 minInform
What went wellAll10 minDiscuss
What didn’t go wellAll10 minDiscuss
Discuss themes & root causesAll15 minDiscuss
Agree improvements: keep / stop / startAll10 minDecide
Assign owners & a check-in date{{Facilitator}}5 minDecide

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

TopicDecision / key noteFollow-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

ActionOwnerDue 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

TopicLeadTimeType
Set the stage: blameless, focus on the system not peopleAisha Khan5 minInform
Action items from Sprint 23 retro — did they land?Aisha Khan5 minInform
What went wellAll10 minDiscuss
What didn’t go wellAll10 minDiscuss
Theme deep-dive: staging flakiness & late QA handoffsAll15 minDiscuss
Agree keep / stop / start improvementsAll10 minDecide
Owners & check-in at mid-sprintAisha Khan5 minDecide

4.Decisions & Notes

TopicDecision / key noteFollow-up
Staging flakinessStop sharing one staging env across squads; spin up an ephemeral env per PRMarco to spike the ephemeral-env setup and report mid-sprint
Late QA handoffsStart bringing QA into refinement so tests are ready before code is doneSam joins refinement from Sprint 25
Apple Pay rolloutKeep the feature-flag + dashboard-alert pattern — it made the launch calmDocument it as the team’s rollout playbook

5.Action Items

ActionOwnerDue date
Spike ephemeral per-PR staging environments and share findingsMarco DiazWed Jun 24 (mid-sprint)
Add QA to sprint refinement and write test cases earlierSam ParkSprint 25 refinement
Write the feature-flag rollout pattern into the team playbookPriya SharmaFri Jun 26
Reduce WIP: cap in-progress stories at four next sprintLena VossSprint 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

  1. Set the stage and review last retro’s action items to open the meeting.
  2. Gather what went well and what didn’t, then discuss themes and root causes.
  3. 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.