Post Mortems Vs. Agile Retrospectives

SoftwareDevTools has been working to improve Agile retrospectives for remote Agile teams using Atlassian tools. We've developed a Confluence tool for Agile Retrospectives, and since it has been successful, we've also developed Agile Retrospectives for Jira. Check them out!.

When addressing this Agile ceremony, we've heard this comparison more than once: "Agile Retrospectives are the same as Post-Mortems". Some teams even claim there's already a Continuous Improvement culture because they do Post-Mortems.

This brought up a question:

How are Retrospectives different from Post Mortems?

In general, Post Mortems are done by a management team after a project is concluded (Post-Mortem = After-Death). While in #Agile software development, Retrospectives are done at the end of each sprint (or whenever needed) during the entire lifetime of the project. It is also different because the Retrospective involves the entire team.

Agile Retrospective for Confluence

Post Mortems Vs. Agile Retrospectives

We'll cover the very basic differences between these two practices:

  • Agile Retrospectives are done periodically during the lifetime of the project. This means that any problems or issues that arise DURING the project, can be also solved while executing. You're better prepared and respond better to changes during this time.

Post-Mortems occur after the project is concluded (or terminated). At this point it is already too late to make a change to improve the way we work, so we'll already have failed or succeeded.

  • Retrospectives are held at the end of every sprint. That's once every 2-6 weeks, according to sprint length, while your memory about issues is still fresh.

Post-Mortems are long feedback loops, once per project might mean every 6-18 months. So, even if that was during the life of the project, the topics covered during the talk are already vanishing memories from the participants. You need fresh knowledge and insights that prompt for faster action.

  • Great retrospectives will generate specific and measurable action items that will have an owner assigned to ensure follow-up. Usually, you start each Retrospectives session by reviewing your previous results and the work that was done since.

Post-Mortems are held by executives or managers, and they often generate very nice reports that are placed on a shelf and ignored. We're not going to lie, this is also often the case for the results of Agile Retrospectives, but with the Agile Retrospectives for Confluence app, or the Agile Retros for Jira version, you'll have increased transparency and accountability in your team.

Agile Retrospectives for remote teams in Confluence

  • Well run retrospectives are always a chance for small improvements and addressing team issues.

Post Mortems sometimes turn into blame and shame events. Mostly a space for complaints.

What other differences can you see?

We want to hear from you! Comment, share & subscribe!

Agile Retrospectives template for Confluence

Trying to improve your #Agile practices? OR are you getting started with Agile? Are you in a remote team? Check out our products for Agile teams at SoftwareDevTools. We focus on making agile ceremonies more effective and easier to adopt for remote teams.

Check out our Atlassian tools:

Follow us on our networks:
Facebook: /SoftwareDevTools
Twitter: @softwaredevtool
And Subscribe to our blog below!


Agile transformation for distributed teams needs the right tools. At SoftwareDevTools we focus on building tools that enable #Agile in remote teams. Real-time collaboration and productive discussions.

Subscribe to SoftwareDevTools

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!