Pre-mortem
Before the next release, imagine failure and backtrack to preventable causes.
Failure scenarios
What could go wrong if everything went sideways?
Causes
Why might those failures happen—root contributors.
Prevention
What will we do now to reduce likelihood or impact?
Signals
Early indicators to watch so we can respond quickly.
This board is for demo purposes only. Your responses are not saved. Close or refresh the page to clear all cards. Do not add any sensitive information.
What is the Pre-mortem?
The Pre-mortem is a forward-looking retrospective format based on the concept developed by psychologist Gary Klein in 1998. Unlike a traditional post-mortem that examines what went wrong after a failure, a pre-mortem asks the team to imagine that the upcoming project or release has already failed spectacularly, then work backward to identify the most likely causes. This technique leverages prospective hindsight—research shows that imagining a future event as already having occurred increases the ability to identify reasons for that event by 30 percent.
The four columns structure the imagination exercise. "Failure Scenarios" captures the ways the project could fail—bugs in production, missed deadlines, user rejection, or team burnout. "Causes" identifies why those failures might occur—root contributors like technical debt, staffing gaps, or unclear requirements. "Prevention" defines what the team can do now to reduce the likelihood or impact of each failure. "Signals" establishes early warning indicators that the team should monitor to catch problems before they escalate.
The Pre-mortem is uniquely powerful because it gives team members explicit permission to voice concerns that social pressure normally suppresses. In a project kick-off, saying "I think this will fail because..." feels negative and disloyal. In a pre-mortem, it is the entire point of the exercise. This psychological safety trick surfaces risks that would otherwise remain hidden until they cause real damage.
When to use the Pre-mortem
The Pre-mortem is most valuable before a high-stakes milestone: a major release, a new product launch, a migration, or the start of a critical project phase. Use it when the consequences of failure are significant and the team would benefit from proactive risk identification. It is also valuable before entering uncharted territory—new technologies, new markets, or new team compositions—where historical data about what goes wrong is limited.
The format works well for teams of five to twelve people and needs 45 to 60 minutes. It is particularly effective when the team includes diverse perspectives—developers, testers, designers, product managers, and operations engineers—because each role sees different failure modes. A developer worries about scalability; an operations engineer worries about monitoring; a product manager worries about user adoption. The pre-mortem captures all these lenses.
Avoid this format immediately after a real failure—the team needs to process what actually happened through a post-mortem before imagining future failures. Also avoid it for routine sprints where the stakes are low. The pre-mortem format requires emotional investment in the imagination exercise, and using it too frequently diminishes its impact.
How to facilitate the Pre-mortem
Set the scene dramatically: "It is six months from now. Our release has failed. The feature was rolled back, users are upset, and we are in a crisis meeting trying to figure out what went wrong. What happened?" Give the team two minutes to absorb this scenario, then seven to ten minutes of silent writing for the Failure Scenarios and Causes columns. Encourage vivid, specific scenarios rather than vague concerns.
Process Failure Scenarios first, reading each one aloud. Do not evaluate plausibility yet—all scenarios are valid at this stage. Then connect each failure scenario to its causes. Often, multiple failure scenarios trace back to the same root cause, which reveals the highest-leverage risks. Dot-vote on the causes that the team considers most likely and most dangerous.
For the top-voted causes, facilitate a discussion to populate the Prevention column: "What can we do in the next two weeks to reduce the likelihood of this cause?" Then define Signals: "What early warning signs should we watch for that would indicate this risk is materializing?" Close by assigning an owner for each prevention action and each signal to monitor. The output should be a concise risk register that the team reviews at every standup or planning session.
Tips for getting the most out of the Pre-mortem
The biggest pitfall is generating failure scenarios that are too vague or too extreme. "The project fails" is not useful. "The checkout flow crashes under load on Black Friday because we did not load-test the new payment integration" is useful because it points to a specific, preventable cause. Coach participants to be specific about the mechanism of failure, not just the outcome.
Do not let the exercise become a fear-mongering session. The goal is not to terrify the team but to channel their anxiety productively. If the mood turns pessimistic, reframe: "Remember, every failure scenario we identify here is one we can prevent. The failures that hurt us are the ones we do not anticipate." This reframing turns the pre-mortem from a scary exercise into an empowering one.
The Signals column is often underdeveloped because teams focus on prevention and forget about detection. Push for specific, measurable signals: "If API response time exceeds 500ms in staging, that is a signal that the production performance risk is materializing." Good signals enable early course correction, which is often more practical than prevention for complex risks that cannot be fully eliminated in advance.
Variations and adaptations
For remote teams, the imagination exercise at the start is crucial and requires extra effort to establish. Consider sending a brief "failure headline" to the team 24 hours before the session—something like "Code Kudu v3.0 Launch Delayed After Critical Data Loss"—and ask people to imagine reading that headline and thinking about what led to it. This pre-priming generates richer scenarios in the live session.
For async teams, the Pre-mortem works well as a two-phase exercise. Phase one (async over 48 hours): team members individually write failure scenarios and causes. Phase two (synchronous 30 minutes): the team reviews, votes on the most critical risks, and collaboratively generates prevention and signal plans. The async phase allows for thoughtful, anxiety-free scenario generation, while the synchronous phase enables collaborative problem-solving.
A powerful variation called the "10/10/10 Pre-mortem" asks: "What could go wrong in 10 days? In 10 weeks? In 10 months?" This temporal lens reveals different risk categories—immediate technical risks, medium-term process risks, and long-term strategic risks—each requiring different mitigation strategies. Another adaptation for teams launching products adds a "User Pre-mortem" lens: "Imagine our users hate this product. Why?" This customer-focused variation surfaces usability and value proposition risks that technically-focused pre-mortems often miss.
Run Retrospectives in CodeKudu
CodeKudu includes dozens of retrospective board templates, anonymous feedback, AI summaries, and action items that sync to GitHub Issues, Jira, and Linear.
