Run a Pre-Mortem in Jira: Find Release Risks Before They Happen

A release can look ready in Jira while the team still has concerns that nobody has written down. The implementation is nearly finished, testing is underway and the launch date is approaching. Someone suspects that older customer accounts behave differently. Someone else worries that support will explain the new controls incorrectly.

A pre-mortem gives those concerns a useful starting point: imagine that the release has already gone badly, then describe what caused it. The exercise makes it easier to discuss plausible failures before the team becomes busy responding to them.

In this guide, we will run a practical pre-mortem for a fictional customer portal release and organize the results in Power Pack’s Risk & Pre-Mortem Grid. The outcome is a short set of risks with clear owners, warning signs and mitigation work.

Choose a specific release outcome

Our team is adding email preferences to a customer portal. Customers will be able to switch optional account emails on or off while continuing to receive essential messages. Maya owns the product outcome, Leo implements the change, Priya leads testing and Sam prepares support.

They choose the Jira issue that describes the shared release outcome as the home for their pre-mortem. Related implementation and testing tickets remain linked through their normal Jira process. Keeping the discussion beside the release issue gives people an obvious place to revisit it.

Before the session, Maya writes a simple scope statement: review the customer experience, email behaviour and support readiness for the first release of preference controls. The team will consider the launch and its first week of use. That boundary keeps the discussion from becoming a review of every possible portal problem.

Imagine a failure before discussing solutions

Start with a concrete prompt: “It is one week after launch. Customers are confused, support requests have increased and we have had to pause the rollout. What happened?” The imagined outcome should be uncomfortable enough to prompt thought without implying that failure is inevitable.

Give everyone a few quiet minutes to write possible causes independently. This lets a tester’s concern or a support observation enter the discussion before the first confident explanation takes over. Ask for causes people can describe, rather than general statements such as “quality was poor.”

Then share the scenarios in turn. During this first pass, collect the concern and clarify its meaning. Save arguments about the best solution for later. A participant should be able to raise an awkward possibility without immediately having to defend a full remediation plan.

• Existing customers see preferences that do not match their current email settings.
• The interface suggests that essential emails can be disabled.
• Support instructions describe controls that changed before release.
• The preference update appears successful even when the underlying change fails.

These are fictional scenarios for our example. Your own list should come from the people who understand the work, the dependencies and the customer experience. Power Pack records the discussion; the team supplies the judgment about what might happen.

Turn concerns into recognizable risk statements

A useful risk describes a possible event and its consequence. “Migration” is a topic. “Existing preference values are mapped incorrectly, so some customers receive optional emails they expected to stop” is a scenario that people can investigate.

Combine duplicates without losing distinct consequences. Several concerns about older accounts might share one underlying cause. A misleading label and a failed save may both confuse customers, but they need different checks and should usually remain separate risks.

For each scenario, ask what the team would notice early. An early warning trigger is an observable sign that deserves attention. In our example, a mismatch between existing account settings and the proposed migrated values is more useful than “customers might complain.” It can be checked before launch.

Agree what likelihood and impact mean

Power Pack offers a 3×3 or 5×5 matrix and calculates a severity score by multiplying likelihood by impact. Use that score to support discussion and sorting. It is a subjective assessment, not a prediction of how often a failure will occur or a calculation of expected loss.

For a first session, our team chooses 3×3 and agrees simple meanings for the ratings. A likelihood of one means they currently see little supporting evidence; two means the scenario is plausible and needs investigation; three means there are strong reasons to expect it without action. These are the team’s working definitions.

They define impact around customer and release consequences. One means a limited inconvenience, two means a meaningful disruption requiring follow-up, and three means a serious customer problem or a reason to pause release. Another team might need different definitions for its own environment.

Priya rates incorrect migration as likelihood two and impact three, giving a score of six. The team discusses the assumptions behind that rating: the new mapping has not yet been rehearsed with representative older accounts. The missing evidence matters more than the apparent precision of the number.

Keep the same scale while comparing the initial risks. Switching between matrix sizes rescales existing ratings, so review the resulting positions if you change resolution. A new position should not be mistaken for newly discovered evidence about the release.

Add the risks to Power Pack

Open Power Pack on the chosen Jira issue and select Risk & Pre-Mortem Grid. Use the heatmap to see the distribution of ratings and the risk register to review the entries. You can add a risk from a matrix cell when you already know its initial likelihood and impact.

For each entry, record the title, failure scenario, early warning trigger and category. Add the agreed ratings, a mitigation plan and an owner. Power Pack also supports mitigation checkpoints, status and an optional Jira issue reference.

The owner can be a Jira user or an external person record. Choose someone who will coordinate the response and bring missing evidence back to the team. Naming that person in the grid does not create a Jira task, assign an existing task or provide access to the issue.

Review the save state before treating the updated grid as shared. Changes are stored against the issue, and a local or retry state should not be read as confirmation that another teammate can already see the latest entry.

Give each important risk a practical response

“Test thoroughly” is difficult to follow up. For the migration risk, Priya proposes a rehearsal using representative existing account states, followed by a comparison of the resulting preferences and expected email behaviour. Leo will investigate any mismatch. Priya remains the risk owner and brings the result to the release review.

Break the response into checkpoints that make progress visible. The team might select representative cases, run the rehearsal, review mismatches and record the remaining uncertainty. Checkpoints help organize the response, while the actual evidence stays in the relevant testing or delivery work.

If mitigation needs its own Jira ticket, create and assign it through the normal Jira workflow, then add its key as a reference on the risk. A reference makes the relationship easier to follow; it does not automatically create the work or manage its delivery.

Revisit status when evidence changes

Power Pack provides Identified, In Progress, Mitigated and Accepted statuses. Use Identified when the scenario has been captured, and In Progress when someone is actively working on the response. Agree what evidence the team expects before describing a risk as Mitigated.

Accepted can describe a conscious decision to proceed with a remaining exposure. For example, Maya might accept a small support-documentation gap after Sam confirms a temporary response is available. Record the reasoning and revisit it if the assumptions change. Acceptance should be an understood decision, not a way to tidy the grid.

At the release review, ask owners about warning triggers, mitigation results and remaining uncertainty. Independently review any material scope change, new dependency or unexpected test result. Update the ratings when the evidence warrants it, and explain why the assessment changed.

You can export the grid as Markdown or CSV for a planning discussion. Identify the Jira issue as the place to check the current record. A shared export is a snapshot and may no longer reflect the team’s latest assessment.

Use the session to change what happens next

A completed grid is useful when it influences preparation. For our portal team, the pre-mortem leads to a migration rehearsal, clearer wording and a check that the support guide matches the release candidate. Each action addresses a specific failure scenario raised by the people doing the work.

Start with one release, a short facilitated discussion and a small set of meaningful risks. Use Power Pack to keep the scenarios, owners and responses visible beside the Jira issue. Then bring the record back into the next release conversation, where the team can assess what has actually changed.