# Pre-Mortem Exercise **Type**:: Planning Activity **Excerpt**:: An exercise to explore probable negative future obstacles or outcomes and how to navigate them proactively. --- ## Resources - [Google Drive Folder](https://drive.google.com/drive/folders/1uRmoKIK4JFHXZFTML2GFK7qGp_MV9KUg?usp=share_link) - [Atlassian Guidance](https://www.atlassian.com/team-playbook/plays/pre-mortem) ## What The engineering or [project pre-mortem](https://hbr.org/2007/09/performing-a-project-premortem) is a type of forward-looking [SWOT analysis](https://www.investopedia.com/terms/s/swot.asp) on a project that helps identify potential pitfalls and risks to project success at the outset. It should involve key stakeholders in engineering and product. ## Why? The project pre-mortem is useful because it sets aside a space for discovering ways a project may be unsuccessful. Specifically, it helps to: - Give the team a space to solve potential pitfalls and develop proactively — and proportionally — strategies to mitigate them. - Avoid [confirmation bias](https://en.wikipedia.org/wiki/Confirmation_bias) in the planning process. - Encourage participation, particularly for individuals who may be skeptical or are otherwise reluctant to speak about a project. ## How? [Atlassian Guidance](https://www.atlassian.com/team-playbook/plays/pre-mortem) **Ibotta Guidance** [Sample Pre-Mortem](https://docs.google.com/document/d/1Xc4mI3t8tuYw2HupQ5wayohv4976T_ukmJheIFyrIt4/edit) — If using Jira, I recommend having a note-taker or otherwise avoiding having everyone throw their notes on the board all at once. In either case, reviewing the ideas presented in Questions 1 and 2 and discussing them as a group is important. ### Part 1: Invite Stakeholders You can participate in a pre-mortem as its own meeting or, alternatively, carve out some time during a normal team ceremony — usually during sprint planning or backlog grooming — if time allows. Stakeholders should include as many squad members as possible and the squad’s product manager. Also, consider involving architecture and representatives from other areas if they will contribute significant effort to the project. #### Set the Scenario Example scenario - total meeting time: 30-45 minutes The basic pre-mortem scenario is a failure scenario: “It is X date (usually anywhere between 3-12 months in the future). The project we are discussing has failed. Customers are unhappy, the product either has shipped in a broken state or breaks constantly. The team is working overtime to fix things, and are burned out.” After setting the stage. Prompt the team with the following questions: #### Question 1: “Why did this happen?” (10-15 minutes) Discuss with the teams the possible factors leading to the above failure scenario. This could include both internal and external factors — e.g. “customers simply didn’t adopt the product,” “the architecture was wrong,” or “we didn’t take enough time to write tests.” This is a space for exploration, so ensure some room for serendipity or outside-the-box thinking.  Encourage everyone to participate. Record these in your Google Doc, such as the [template](https://docs.google.com/document/u/0/d/1sEVQheAyEXYagNeg_f3Vi0YZTyoUv-NZS5mWUKpecsk/edit), for the exercise.  #### Question 2: “What can we do between now and X date to avoid this?” (15-20 minutes) For each failure mode listed in Question 1, take some time to discuss what the team can do to avoid them. Record the responses with each of the failure modes. Note: The goal for Question 2 is to evaluate and prioritize proportional responses to real risks to the project timeline. Consider “risk” vs “exposure” (What are the odds of this happening?  What are the consequences if it does?). For every answer, challenge the team: “Is this mitigation or solution proportional to the risk?” While AI taking over the world and simultaneously powering off every internet-connected computer may be a risk to the project deadline, it is likely more appropriate — and proportional — to focus on right-sizing queues to account for unanticipated demand on a service or to ensure the team’s on-call rotation and run books are up-to-date. ### Part 2: Schedule and Prioritize responses from Question 2 above (5-10 minutes) Once you have brainstormed the problem/solution framework above, create stories in Jira and prioritize the work as appropriate.