What is a post-mortem retrospective?
A post-mortem is the conversation your team has after something ends. Sometimes that something is an incident: a system broke, a release went sideways, a customer felt the pain. Just as often it's an ordinary project that has wrapped, and you want a clear agenda for the review instead of inventing one from scratch. This template handles both. You set the frame with the project's goals and scope, walk through what went well and what didn't, dig into root causes where it matters, and turn the honest parts into lessons learned your organization can reuse. Here's how it works in TeamRetro. Everyone adds their own observations privately first, so the loudest voice in the room doesn't set the story before quieter people have written anything down. Ideas are then grouped, discussed and voted on, which lets you focus on the handful of themes that matter instead of working through forty comments in no particular order. That's the difference between this and a document you fill in alone: it's a live debrief your whole team runs together, and it ends with owners and due dates on real actions, not a report nobody opens again. Use it as your default project review at the close of a delivery, a campaign, a migration or a quarter, and as your incident review when something has gone wrong and you need a blameless account of the timeline and its causes. The final topic makes space for kudos, because recognizing the people who carried the work is part of closing it out properly. Either way, the team should leave knowing what to repeat, what to stop and who's doing what next. Export the report when you're done, so the lessons stay findable for the next team that walks into the same situation.
Post-mortem retrospective format
Project overview, goals and scope
What did the project set out to do, and by when?
This topic sets the frame before anyone judges anything. Ask for the original objective, the agreed scope, the timeline and the success criteria, plus what was actually delivered against them. For an incident review, use it for the timeline instead: what broke, when it was detected, who was involved and how it was resolved. Keep interpretation out of this column and save opinions for the topics that follow. If people disagree on what the goals or success criteria even were, that disagreement is a finding worth capturing.
What went well
Which wins and processes are worth repeating?
Teams rush past this topic, especially after a difficult project or a stressful incident, so protect the time for it. You're looking for practices worth repeating, not compliments; kudos have their own topic later. When someone posts praise, ask what specifically made it work so the answer can be reused. Watch for wins that came from individual heroics, and name them as risks.
What didn't go well
Where did we stall, break or miss targets?
This is where most of the learning sits, so say the blameless ground rule out loud before you start: you're examining systems and decisions, not people. Ask for specifics over vague grumbles. "Communication was bad" can't be acted on, but "we found out about the deadline change in a hallway conversation" can. Use voting so the discussion doesn't sprawl across every irritation of the last three months.
Root cause analysis
Why did it go wrong, not just that it did?
Optional for a straightforward project review, essential for an incident. Take the top-voted problems from the previous topic and keep asking why until you reach a condition, not a person: a missing guardrail, an unclear owner, schedule pressure, an assumption nobody tested. The Five Whys works well here, and so does asking what made the wrong action look reasonable at the time. Stop when you reach something you can actually change, and note contributing factors separately from the trigger.
Lessons learned
What lessons do we carry forward?
This is the "so what" that turns observations into knowledge you can reuse. Push each idea until it names a behavior, a trigger or a guardrail that will still make sense on the next project. Separate what this team can change itself from what needs to go to a manager or another group, and be honest about the second list. Write each lesson so someone outside the room could read it in the exported report and understand it without you there to explain.
Action items, owners and deadlines
Who is doing what, and by when?
A post-mortem without assigned actions doesn't count, so leave real time for this instead of squeezing it into the last two minutes. Turn the top-voted lessons into a small number of specific actions, each with a named owner and a due date recorded in TeamRetro so they come up at your next session. Two or three well-owned actions beat ten aspirational ones. If an action belongs to someone outside the room, agree who will take it to them and by when.
Team appreciation and kudos
Who deserves recognition before we close out?
Close on the people, not the problems. Ask everyone to name a specific person and a specific thing they did; it means far more than general thanks and works even after a difficult project. It matters most when the review has been hard going, because it reminds the team that examining a failure isn't the same as blaming each other. Keep it quick, read a few aloud and let the exported report carry the rest.
When to use this retrospective
- A project, delivery, migration or campaign has just wrapped and you want a structured review, not an informal chat that fades away
- An incident, outage or failed release needs a blameless post-mortem covering the timeline, root causes and preventive actions
- A long-running program has finished a phase and you want lessons learned captured while the details are still fresh
- A cross-functional group is disbanding, and this is your last chance to debrief and recognize contributors before people move to new work
- Something went unexpectedly well and you want to understand why, so you can repeat it instead of putting it down to luck
Suggested icebreaker questions
- In one word, how did this project or incident feel while you were in the middle of it?
- If you could send one sentence of advice back to yourself on day one, what would it say?
Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →
Ideas and tips for your retrospective meeting
- Run it within a week or two of the project closing or the incident being resolved. Memories fade fast, and the useful detail goes with them
- State the blameless rule at the start. You're looking at decisions, systems and pressures, not searching for someone to hold responsible
- Spend a few minutes agreeing on the project overview before opinions start. A shared frame stops the session turning into a debate about what the goal even was
- Skip or shorten root cause analysis for a clean project review, and spend more time on it for incidents where prevention is the point
- Prioritize with voting, then don't let the meeting end without owners and due dates on the top actions, or your lessons learned stay theoretical
- Bring the previous post-mortem's actions into the room and review them first. Nothing improves follow-through like knowing it will be checked
Frequently asked questions
What is a project post-mortem?
How is a project post-mortem different from an incident post-mortem?
What should you include in a project post-mortem?
Do I have to use the root cause analysis topic?
How long does a post-mortem take?
Who should attend a post-mortem?
Related templates
Close out last year and set this year's team goals.
Timeline Retrospective
Map the key events of a project and how the team felt along the way
End of Year Retrospective
Look back on your team's year and plan the next one
Project Kickoff Planning
Agree on goals, risks and milestones before work starts.