Pre Mortem

A forward-looking format that imagines failure before it happens. The team pretends the project has already failed and asks why — what went wrong, what wasn't done, which problems remain and what other concerns linger. Surfacing risks at the start makes them far easier to prevent than to fix after the fact.

(Hypothetical) The project was a failure! What went wrong?

Imagine the project already failed — describe how it happened

Roman

We launched into peak season and the payments queue collapsed

Maria

The migration ran long and we rolled back with partial data

What didn’t we do?

Steps the team skipped on the way to that failure

Anna

We never load tested against realistic traffic

Daria

We never wrote a rollback plan anyone had rehearsed

What current problems remain?

Problems that exist today and would make the failure worse

Maria

Only one person understands the billing deploy

Kirill

Staging still does not match production data shapes

Any other concerns?

Anything else that nags at you and has no owner

Daria

The vendor API deprecation lands in the same window

Roman

Two people are on leave during the launch week

Try Template

What is the Pre-Mortem retrospective?

A Pre-Mortem runs before the work begins, not after. The team imagines it's the end of the project and it has failed, then works backward to explain why. This "prospective hindsight" makes people far more honest about risks than a normal planning meeting, surfacing dangers while there's still time to prevent them.

What could go wrong? — risks and failure modes
What didn't we do? — gaps and missing steps
What problems remain? — unresolved threats
Other concerns? — anything else on people's minds

What could go wrong?

The team brainstorms every plausible way the project could fail: technical risks, dependencies, unrealistic timelines. Naming threats out loud early is what makes them manageable.

What didn't we do?

Here people spot gaps in the current plan — steps skipped, preparation missing, stakeholders not aligned. Catching these now is far cheaper than catching them later.

What problems remain?

This column captures known issues that still aren't resolved: open questions, unclear ownership, unmitigated risks that could quietly grow into failures.

Other concerns?

A space for everything else — gut feelings, soft worries and edge cases that don't fit neatly elsewhere but deserve to be on the table before work starts.

Benefits of the Pre-Mortem retrospective

Surfaces risks before they cause real damage
Makes it safe to voice doubts about the plan
Turns vague worries into concrete mitigations
Improves planning and realistic estimates
Builds shared ownership of project risks
Cheaper than fixing problems after they hit

How to run a Pre-Mortem retrospective

Create a board in QRetro from the Pre-Mortem template.
Set the scene: imagine the project has already failed.
Have everyone add cards across all four columns silently.
Group related risks and discuss the most serious ones.
Prioritise the risks that most threaten success.
Assign preventive actions and owners for the top risks.

Similar templates

Other formats teams pair with this one — open any of them as a board in one click.

Went Well - To Improve - Action Items

A classic retrospective for reviewing the results of a sprint or stage of work. The team captures what worked well, where it lost momentum and which concrete steps will move things forward. The simple three-column structure keeps the focus balanced between celebrating successes and turning problems into action items that the team can actually take ownership of.

Start - Stop - Continue

An action-oriented format that pushes the team toward concrete decisions rather than abstract discussion. Participants name practices worth starting, those to stop because they get in the way, and the ones that already work and should continue. The result is a clear, immediately usable list of changes that supports a culture of continuous improvement.

4Ls Retrospective

A simple, popular method for Scrum Masters and their teams that captures both the positive and the negative sides of a sprint. Across four lenses — what people liked, what they learned, what they lacked and what they longed for — the team gathers honest feedback and turns it into ideas for improvement. The structure makes it easy for everyone to contribute, even in quieter teams.

Sailboat Retrospective

A metaphorical exercise that turns reflection into a picture of the team's journey. The wind represents what moves the team forward, the anchors what holds it back, the rocks the risks lurking ahead and the island the shared goal everyone is sailing toward. The visual framing makes it easier to talk openly about obstacles and align around where the team wants to go.

Mad Sad Glad

Mad, Sad, Glad helps a team explore how it felt about the past sprint before moving on to the next one. By naming what made people angry, what saddened them and what brought joy, the team surfaces emotional signals that plain metrics miss. Done well, it builds emotional awareness, strengthens team spirit and turns frustration into a constructive conversation.

Thumbs up, Thumbs down, new ideas and recognition

A light, balanced format that keeps the conversation moving between the good, the bad and the forward-looking. The team marks what deserves a thumbs up, what gets a thumbs down, the new ideas worth trying and the people worth recognizing. Adding recognition to the mix keeps the tone positive while still leaving room for honest criticism.

Try Template