Post-mortems vs Retrospectives: What’s the Difference?
Picture this. After months of work, you’re done. Your big feature or project has been released, customers are reaping the rewards of your work and your team is overjoyed. Celebratory drinks are ordered. Everyone breathes a big sigh of relief.
Then, your boss turns to you and says, “Congrats! What should we do better next time?”
You’re mystified. Not only was that a bit of a downer, but also, you’re not sure how to even begin finding the answer to that question.
When a block of work (a project, a sprint, a feature) is complete, there are four important questions to ask:
- What were we trying to accomplish?
- Where did we hit (or miss) our objectives?
- What caused our results?
- What should we start, stop, or continue doing?
Different types of teams have different methods for asking these questions.
Let’s look at two common formats for debriefing on work – the post-mortem and the retrospective – and understand what each of these terms mean, how the approaches are similar and different, and which one you should use for your next debrief.
Why do we need to do a post-mortem, sprint retrospective or any kind of debrief?
First, let’s establish why you’d even want to consider either of these formats, besides your boss asking you to.
Many teams are bogged down by too many meetings, so asking team members to spend yet more time talking about work instead of doing work is a hard sell.
But reflecting on your previous experience is a critical step in creating continuous team improvement. Without an opportunity to examine what happened, teams often follow the same patterns for cycles on end – doing more work, but not improving how they work.
In development terms, we might say teams close more issues, but the velocity of closing issues stays the same as does the quality of the code, not to mention the mood of the team.
The ultimate goal with any kind of debrief is to reflect on how you’re working so you can iterate on your processes and systems.
Post-mortems and retrospectives are different ways to frost the same cake: whichever format you choose, the goal is to understand the patterns of behavior on your team, so you can improve them in future.
While they have the same goal, post-mortems and sprint retrospectives have different intentions and processes, which mean you get different results depending on which you choose.
Post-mortems attempt to understand what went wrong
Post-mortem literally means ‘after death’. As the name suggests, after a patient dies, doctors work to understand the cause of death.
In the world of product development, post-mortems typically take place after something is completed, and attempt to understand why it turned out the way it did.
Post-mortems include three parts:
- 📝 Pre-meeting survey: A manager or lead writes up a series of questions and sends them to stakeholders. Stakeholders typically include the main team working on the project, and also key senior people who are impacted by the project, such as support leads, senior designers, or others. The purpose of this phase is to collect quantitative data, so questions tend to be multiple choice or data-focused, to get a sense of trends across the group. These might include yes/no questions or rating questions, for example:
Were changes in project scope and expectations communicated adequately? Yes or No
On a scale from 0 (not at all) to 10 (completely), rate how much you agree with the following statement: I felt adequately involved in decisions that impacted my work on this project.
- 📈 Data analysis: Once stakeholders have responded, the data is analyzed to identify trends and insights. This analysis might be done by the same person who wrote the survey initially, or another member of the company’s leadership team.
- 👔 Meeting to present and discuss results: With insights in hand, the team hears a presentation around survey findings and discusses what to make of the results.
Often, the final outcome of a post-mortem is a report for leaders, who may or may not be part of the team implementing the work.
As the name implies, typically, post-mortems happen after something – a big milestone, a project, or an incident like an outage, hack or other failure.
Because the name implies understanding what went wrong, post-mortems sometimes only happen when that ‘something’ is negative, which means there’s not as much reflection when things go well.
As you can imagine, this format comes with some pros and cons.
Post-mortem benefits
- Because post-mortems typically focus on finding a cause, they appeal to managers and leaders seeking to understand why things are happening. Presenting findings to the whole team gives the team power to evolve how they work together.
- Since post-mortems come after a problem, it’s relatively easy to explain the value: you want to avoid whatever went wrong from happening again. This makes a post-mortem an easy first step towards continuous improvement.
- Because they only happen after big events, post-mortems feel like a smaller commitment, and often take up less time, than an on-going practice like sprint retrospectives.
- You can compare the quantitative data gathered during a post-mortem from project to project, allowing companies to concretely track whether they’re improving.
Post-mortem limitations
- While it’s clear why managers benefit from a cause-focused approach, team members can feel uncomfortable with this top-down method and the discussion can quickly turn to blame, rather than improvement.
- Because post-mortems happen at the end of something, there’s no opportunity to reflect and improve along the way. Depending on how frequently issues crop up, creating continuous improvement can feel more like a process of fits and starts.
- Where post-mortems focus on hard data, they can miss subtler, qualitative evidence. A survey may ask about how productive team members felt on a scale from one to ten, but miss that most folks only felt productive at the end of the project.
- Finally, because post-mortems start with someone formulating the questions, much depends on how well the questions are formulated. Even experienced leaders can forget to ask important questions, and team members have limited options to bring up their feedback when they aren’t explicitly asked about it.
Retrospectives create continuous reflection and improvement
To retrospect means ‘to look back’, the connotation being to reflect on what happened and improve. So a retrospective meeting is one that looks back over a project or sprint and lets team members reflect on how it went.
Retrospectives include four phases:
- 🟨 Reflect: Team members add reflections, traditionally on sticky notes. Leaders may choose from any number of popular sprint retrospective templates to vary the prompts that team members are responding to.
- 📎 Group: Team leads group reflections according to patterns they see in the feedback. This typically happens on a whiteboard with the team, so participants can collaborate by calling out ideas on what should be grouped. With an online tool, the whole team can group reflections directly.
- 🗳 Vote: Team members each get a number of votes, and chose which topic groups are most interesting or important for them to discuss.
- 💬 Discuss: Starting with the topic group that got the most votes, team members discuss each group, and determine what actions they want to take in response.
Traditionally, the whole process takes place in a conference room, with the whole team in attendance. Nowadays, teams might prefer to gather reflections throughout a sprint rather than at the end, or hold the entire process asynchronously to engage more team members, including those working in other time-zones or remotely.
Retrospectives are a standard part of the agile development cycle, often coming at the end of each sprint, or approximately every 2 weeks, though different teams prefer different cadences for their retrospectives.
The outcome of a sprint retrospective is a set of tasks to improve the team. With online tools, teams might also have a meeting summary to remind them what was discussed.
Retrospective benefits:
- Because they happen at regular intervals, sprint retrospectives encourage continuous improvement, rather than ad-hoc iteration.
- Since reflections can take any format the team chooses, retrospectives make room for qualitative evidence. Subtle information about how someone is feeling or what’s getting in their way can yield rich insights for the team.
- The team takes the lead in every step of a retrospective meeting, putting the power in their hands to improve their own work.
- Since sprint retrospectives are part of the agile process, they don’t only take place when something has gone wrong. Rather, because they occur regularly, improving how the team works is baked right into the process of doing work.
Retrospective limitations:
- Since there’s a less clear tie to outcomes, goals or milestones, managers can have a harder time understanding the purpose of retrospectives, especially when they haven’t worked in an agile environment before.
- Because the output of a retrospective is tasks within an existing tasking system, the true outcome of a retrospective can be lost, with no fancy report to share.
- As retrospectives are typically held as meetings, team leads need to take on the role of facilitator – choosing a template, getting people to share their thoughts and guiding the grouping phase. Without strong facilitation skills, teams can fall into boring or ineffective meetings.
- Since retrospectives aren’t focused on finding the why behind something, you may not learn much about why a specific outcome occurred. Experienced facilitators can craft a template to serve this goal, but it’s not a direct part of the retrospective format.
How to choose between a post-mortem or a retrospective
The first step is determining that you want to do something. Once you’ve committed to reflecting on your work, the hardest part is over – you’re on your way to improvement.
From there, you need to ask yourself a series of questions about what you’re trying to accomplish. These should cover three main areas: intention, output, and people.
1. Intention: Why do we want to run a debrief?
To decide between a sprint retrospective and a post-mortem, first ask yourself what sparked your interest in doing a review or debrief in the first place.
Since the two formats are geared towards answering different types of questions, you need to know what you’re reflecting on and what you want know about that work.
If something went wrong, or something significant happened – a big milestone, project or feature – you probably want to conduct a post-mortem to understand what happened.
If nothing in particular happened, but you believe you’re not doing the best work you could be, and want to improve, you probably want to try running a sprint retrospective to start regular discussions about what to improve.
2. Output: What do you want the result to look like?
After going through these two different processes, you’ll be left with different results and much different outputs.
If you want to create a report that explains what happened and why, a post-mortem format is likely a better fit. A post-mortem specifically looks at hard evidence and attempts to break down why something happened. Because it starts with quantitative data gathering, the post-mortem format lends itself better to a presentation or report at the end.
If you’d rather have action items within your team to help you improve, then a retrospective format is probably a better fit. A sprint retrospective asks the team to take ownership over their own processes and improve how they work together. When you identify the patterns together, the power is in your hands to decide what to do with it, and even add tasks to your to-do list during the meeting.
3. People: Who is asking for a debrief and who should participate?
Finally, post-mortems and retrospectives serve different audiences.
Post-mortems generally serve the needs of managers and other leads who want to understand whether something went well or not, and why. Additionally, because feedback is gathered in a survey and then presented to an audience, post-mortems allow you to engage a broader array of stakeholders – analysts, senior leaders, support staff and the team itself – to give feedback. If you want to include this broader group and create something for managers, then a post-mortem is a better fit.
Retrospectives, on the other hand, primarily engage and serve the team doing the work. Only direct team members are typically involved in sprint retrospectives, and both the discussion and action items coming out of a retrospective primarily serve the teams’ needs. While a more effective team obviously supports the needs of both leaders and other stakeholders, the team itself enjoys the primary benefits of a retrospective.
Because retrospectives focus on the team, asking to run a retro can be a wise move if you’re feeling unsatisfied as a team member. Rather than giving feedback directly to a lead and hoping they act on it, a team member can ask for the team to participate in a sprint retrospective process, which often feels like an easier request. From there, they have the space to reflect on what’s working and what’s not.
But what’s in a name? It doesn’t matter what you call it – define your principles first
Now that we’ve spent some time breaking down the difference between post-mortems and retrospectives, I’m going to tell you something you might find infuriating: it doesn’t really matter.
Post-mortems and retros are just two ways to frost the same cake. They’re different techniques to get at understanding how your team can improve.
And if you look around the Internet, you might find that there are lots of instructions for how these things should work, and they don’t all agree. People use the terms post-mortem and retrospective interchangeably, and they mean different things to different people.
It doesn’t really matter what you call your review process or debrief practice, as long as you and your team understand what you’re talking about, and it helps you to work better together.
But what does matter is having your practice align with your principles.
Here are some guiding principles to keep in mind when running your debriefs:
- ⏳ Gather and reflect at regular intervals: Don’t wait for something to go right or something to go wrong. Rather, reflect on your work at regular intervals. The more often you reflect, the faster you’ll improve – and the goal is continuous improvement, meaning to ABI (always be improving).
- 🙉 🙊 🙈 Include a variety of evidence: Quantitative and qualitative data offer different perspectives on what’s happening with your team and organization. Find ways to draw on both to get a fuller picture, and create more opportunities for meaningful improvement.
- 😎 Work at the level your team is comfortable with: The more open-ended discussion-based nature of a retrospective can be intimidating to some. Perhaps this less hierarchical approach is too new, or they have more introverted tendencies. In that case, jumping head-first into a retro might be challenging. On the other hand, maybe your team prefers lean processes, and has a strong bias for one meeting rather than a multi-step review. Then, a post-mortem might feel cumbersome, and a sprint retro would be a better fit. Whatever your team culture, think about how you respond to different kinds of processes, and try something more suited to your specific way of working.
From these principles, you can mix and match formats in whatever way brings you joy – and support your teams’ continuous improvement.
Start on the path to continuous improvement
Flash back to that hypothetical scenario where your boss asked how your team was doing, or how the project went.
Armed with an understanding of post-mortems and retrospectives, you can now recommend a process that’s right for your team and helps you understand how to improve the way your team works.
Whether you find that retrospectives are more your style, or that post-mortems better suit your needs, the key is to make it happen.
Continuous improvements starts with reflection on your work in whatever cadence or format makes sense to you.
💡 Check out our complete guide to project retrospectives, covering pre-mortems, post-mortems, lessons learned meetings, after-action reviews, and more!
