/

Templates / Projects and agile

Retrospective and post mortem

Retrospective meeting template

A retrospective or post mortem looks back at a sprint, project or incident and ends with a short list of changes, each with one owner. The notes should check whether last time's actions were done, lay out a timeline of what happened, list what went well and what didn't, name the causes the team can act on, and record two or three actions with dates.

Best forAgile teams after each sprint, and any team after a project, launch or incident

Meeting length45 to 60 minutes for a sprint, 60 to 90 minutes for a project post mortem

SectionsLast actions, timeline, what went well, what didn't go well, why it happened, actions

FormatsGoogle Docs, Word, Notion, Markdown

Word Markdown

Retrospective notes: [sprint, project or incident].docx

Retrospective notes: [sprint, project or incident]

Reviewing PeriodStart and end datesDate Attendees Facilitator Notes by

Actions from last retro

Action	Owner	Status
		Done / In progress / Dropped

Timeline

Date	What happened
	Facts only, no opinions yet

What went well

Specific enough to repeat

What didn't go well

Problem	Votes
Described as an event, not a person

Why it happened

Problem	Cause	In our control?
		Yes / Partly / No, and who could change it

Actions

ID	Action	Owner	Due	How we'll know it worked

Word MarkdownPastes into Google Docs, Word or Notion with headings and tables intact.

Word Markdown

Retrospective and post mortem agenda.docx

Retrospective and post mortem agenda

ReviewingSprint, project or incidentDate Time60 minFacilitatorSomeone not deeply involved in the work, if possibleNotes by

Item	Owner	Time	What we need to leave with
Ground rule and purpose	Facilitator	3 min	Everyone has heard the no-blame rule
Actions from last retro	Facilitator	5 min	Each action marked done, in progress or dropped
Timeline of what happened	Project lead	10 min	An agreed order of events with dates
What went well and what didn't (silent writing)	Everyone	10 min	Input from every person, not just the loudest
Group and vote	Facilitator	7 min	The top 2 or 3 problems to dig into
Why it happened	Everyone	15 min	A cause the team can act on for each top problem
Actions and read-back	Notes taker	10 min	2 or 3 actions, each with one owner and a date

Word MarkdownPastes into Google Docs, Word or Notion with headings and tables intact.

Cedar & Salt online ordering launch, post mortem

Filled-in example

Cedar & Salt online ordering launch, post mortem

ReviewingOnline ordering launch at three restaurant locationsPeriodAugust 24 to October 23, 2026DateWednesday, October 28, 2026, 3:00 to 4:05 pmAttendeesJess Albright (operations manager, project lead), Kofi Mensah (IT contractor), Laura Pineda (marketing), Tim Holloway (general manager, Elm Street)FacilitatorRavi Shah (finance, not on the project team)Notes byLaura Pineda

Actions from last retro

Action	Owner	Status
Get menu sign-off from all three head chefs before anything is published (spring menu refresh)	Jess	Done. Used again for the online menu.
Keep one shared launch checklist instead of email threads	Laura	Dropped. Never set up, and it came up again today.

Timeline

Date	What happened
Aug 24	Project approved. Launch set for Oct 1 to match the fall menu campaign.
Sep 8	Ordering platform contract signed, two weeks later than planned
Sep 28	Test orders: the kitchen printer at Elm Street doesn't print online orders
Sep 29	Last location's menu photos and item details delivered (due Sep 21)
Sep 30	Launch moved to Oct 15. Customers emailed the new date.
Oct 9	Printer vendor updates the Elm Street printer
Oct 13 and 14	Kitchen and front-of-house training at all three locations
Oct 15	Launch at all three locations
Oct 16	Friday dinner at Elm Street: 11 online orders ready late, two refunded

What went well

Every shift was trained before launch. No order-handling mistakes in the first week.
Kofi's test order plan caught the printer problem before any customer did.
The new launch date email went out the same day the date moved. 140 online orders in week one.

What didn't go well

Problem	Votes
Launch date announced before the platform contract was signed	4
Printer compatibility only checked in test week	3
Elm Street Friday rush: online orders competing with dine-in tickets	3
Menu details arrived late from one location	1
No shared checklist, status lived in Jess's inbox	1

Why it happened

Problem	Cause	In our control?
Launch date before contract	The date came from the marketing calendar, not a delivery plan	Yes
Printer found late	Nobody owned hardware. The platform's setup checklist assumed newer printers.	Yes
Elm Street Friday rush	The limit on online orders per 15 minutes was off by default. Staffing may also be a factor.	Partly. Tim wants two more Fridays of data before deciding on staffing.

Actions

ID	Action	Owner	Due	How we'll know it worked
R1	Add a contract-signed check and a two-week buffer to the project approval form	Jess	Nov 6	Updated form used for the catering portal project
R2	Make hardware compatibility a named task with an owner in every IT project plan	Kofi	Nov 13	Line added to the project plan template
R3	Turn on the online order limit at Elm Street for Friday and Saturday dinner	Tim	Oct 30	Setting on, late orders checked after Oct 30 and Nov 6
R4	Decide who owns a shared launch checklist	Jess (to raise at the Nov 4 ops meeting)	Nov 4	A named owner. Still unassigned after two retros.

Cedar & Salt and everyone named here are a fictional sample.

Best forAgile teams after each sprint, and any team after a project, launch or incident

Meeting length45 to 60 minutes for a sprint, 60 to 90 minutes for a project post mortem

SectionsLast actions, timeline, what went well, what didn't go well, why it happened, actions

FormatsGoogle Docs, Word, Notion, Markdown

What to write in each section

Ground rule

Say it at the start: we're looking at how the work was set up, not grading people. Assume everyone made reasonable choices with what they knew at the time. In a post mortem, this is what gets people to tell you what really happened.

Actions from last retro

Check each one before anything else, the same way a good meeting agenda puts open action items first. If last time's actions weren't done, that is usually the first thing to talk about.

Timeline

For a post mortem, list the key events with dates before anyone offers opinions. People remember the order of events differently, and agreeing on the facts first saves a lot of arguing. For a routine sprint retro, skip it or keep it to a few lines.

What went well

Specific things to repeat next time.

"Good teamwork" doesn't help the next project. "Every shift trained on the new system two days before launch" does.

What didn't go well

Problems described as events, not as people. Let everyone write silently first, then group duplicates and vote on the two or three that cost the most.

Why it happened

For each top problem, keep asking why until you reach something the team can change. If the cause is outside your control, say so and note who could change it.

"Testing was rushed" is a symptom. "The launch date was set before the contract was signed" is a cause you can do something about.

Actions

Two or three, each with one owner, a date and how you'll know it worked. A list of ten actions usually means none of them happen. Keep them in an action items tracker so they're easy to check next time.

When to use this template

Your retros produce the same complaints every two weeks and nothing changes.
A project or launch went badly and you need to review it without it turning into blame.
A project went well and you want to know why, so the next one runs the same way.

Questions people ask

What is the difference between a retrospective and a post mortem?: A retrospective is a regular review, usually at the end of every sprint (before the next sprint planning), about how the team works. A post mortem looks at one finished project, launch or incident, so it spends more time on the timeline. This template works for both: skip the timeline for a routine sprint retro.
Who should facilitate a post mortem meeting?: Someone who wasn't deeply involved, so they can ask plain questions and keep it from becoming a defense of decisions. The project lead should attend and walk through the timeline, but not run the meeting.
How do you stop retros from repeating the same problems?: Start every retro with last time's actions and cap new actions at two or three. If a problem keeps coming back, the fix usually sits outside the team, so name the person who can change it and take it to them.

Related templates

Scrum meeting template for sprint planningScrum teams, typically 10 or fewer people including the product owner and scrum masterAgenda · Template · Example

Project status meeting templateProject teams and stakeholders, weekly or every two weeksAgenda · Template · Example

Project kickoff meeting templateProject managers starting an internal or client project with a new teamAgenda · Template · Example