Post-mortems vs. retrospectives: What’s the difference?
The end of a project is always everyone’s favorite part. The hard work has paid off, and the team can enjoy a well-deserved break. That said, there’s a lot you can learn from the last project or sprint you have completed. The question is, what’s the best way to assess your team’s work and learn from it?
Regulars to our blog won’t be surprised to see us recommend a retrospective. We’re also going to talk about post-mortems because they’re another invaluable tool you can use to assess previous work. The two can sometimes be interchangeable as they deal with learning from previous work and looking at what went right and what you can improve. But they are different tools to have in your toolbox for different situations.
Post-mortems vs. retrospectives
Because these two tools are regularly confused, let’s break down the key differences between post-mortems and retrospectives.
Timing
The most obvious distinction between the two is timing. As the name may suggest, a post-mortem takes place once the entire project is complete, hence the name: “after death.”
Retrospectives are much more frequent and can be performed after every sprint to enable the team to make essential changes on a dime.
Amount of work examined:
It won’t surprise anyone to know that you will be looking over more work during a post-mortem than you will during a retrospective. Depending on how long the project has run for, you may end up analyzing a year’s worth of work during a post-mortem. With a retrospective, the workload is much smaller, limited to a few weeks.
Focus
Focus is where post-mortems and retrospectives tend to cross over — both highlight what went well, what went wrong, and what can be improved. The only thing that changes between the two is scale. Post-mortems will focus on significant successes or failures, while retrospectives will identify more minor successes or issues.
Who participates?
As retrospectives are a regular, smaller-scale event, they only need the core development team to participate. Others involved in the project are welcome to join, but not essential.
Post-mortems are a much more inclusive format as they deal with the aftermath of a complete project. Managers and other leads who want to understand whether something went well or not (and why) should attend a post-mortem. Post-mortems allow you to engage a broader array of stakeholders — analysts, senior leaders, support staff, and the team itself — and gain feedback from a wider group.
What happens after?
If we’re honest, the outcome of a post-mortem and a retrospective will be pretty similar. By the end of each meeting, you will have a list of successes and failures you need to act on in the future. That said, what you come out of each type of meeting with, and what you need to do with it, will be different, as we mentioned earlier.
A retrospective will leave you with a shortlist of relatively small tasks your team needs to complete during the next sprint. These can be as simple as a bug fix or a little more complicated, like a product’s UI revamp. The team will walk away with a list of what to change and head straight to work.
A post-mortem will leave you with a list of all the successes and failures during the project. The likelihood is, you won’t use this information again. However, it will offer learning opportunities your team can implement during the next project or even deploy throughout the entire business.
How to choose between a post-mortem and a retrospective
Both formats yield different results, so it may not always be appropriate to run a post-mortem at the end of a project. Sometimes a simple retrospective may be all you need! So to figure out which you need to perform, you should ask yourself a series of questions about what you want to achieve from the meeting.
What do you want to achieve?
To decide between a sprint retrospective and a post-mortem, you need to identify what you hope to achieve from the meeting. What do you want to know? What do you plan to do with the information?
Say something went drastically wrong and derailed the entire project or something significant happened — a big milestone, project, or feature — you probably want to conduct a post-mortem to understand what happened.
If the project ticked along nicely with nothing out of the ordinary occurring, you likely won’t need a post mortem. However, if you believe the team could improve, you can run a sprint retrospective to identify how to improve and which areas need more attention.
How do you want your results to look?
After going through these two different processes, you’ll end up with different results and different outputs. If you want to create a report that explains what happened and why, a post-mortem is likely a better choice. A post-mortem will specifically look at hard evidence and attempt to break down why something occurred. Because it starts with quantitative data gathering, the post-mortem format is perfect if you need a presentation or report.
If you’d rather have a list of actionable items within your team to help them improve, then a retrospective format is probably the move. A sprint retrospective asks the team to take ownership over their processes and improve how they work together. It’s a chance for the development team to develop themselves and head into the next project with the knowledge and power to move forward.
Who’s asking for a debrief, and who should participate?
As we mentioned earlier, 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 wider 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 serve the teams’ needs. While a more effective team supports the needs of both leaders and other stakeholders, the group 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 the team to participate in a sprint retrospective process, which often feels like a more straightforward request. From there, they have the space to reflect on what’s working and what’s not.
Ready to run your post-mortem?
So now you know the difference between the two, why not host your post-mortem when your next project comes to an end? For all the information you need to run a successful post-mortem meeting, check out our guide, complete with a free template to get you started!