“It’s November 19th. The release we’re committing to today has missed. What happened?”
The room is quiet for a moment, and then it isn’t. The staff engineer says the payments-platform dependency landed two sprints late, the way it did last time. The Scrum Master points at May: two parental leaves and a cluster of public holidays that never made it into the plan. The product owner admits that compliance “discovered” new requirements in week seven, because compliance always does. Twenty minutes of imagined failure, and the whiteboard holds a more honest risk list than any register the program owns.
That is a premortem working exactly as designed. Gary Klein’s technique flips the timeline: instead of asking what could go wrong — a question rooms tend to answer politely — you declare the project has already failed and ask what did. The research behind it, on what psychologists call prospective hindsight, found that imagining an outcome as certain makes people roughly 30% better at identifying the reasons it happens. A premortem isn’t pessimism, and it isn’t gut feel. It’s expert engineering judgment, given a format that finally makes it safe to say out loud.
The premortem list goes in a drawer
Here’s the part nobody writes about: what happens to the list. The whiteboard gets photographed. The photo lands in a slide appendix, or a RAID log that refreshes monthly if it refreshes at all. Then the release runs for ten weeks while nobody checks whether the failures the team predicted are actually arriving.
Which is a strange way to treat a document that is usually right. Run a premortem on any software release and the same three failure modes fill most of the whiteboard: scope will grow, a dependency will surface late, and capacity will change. Those are precisely the three things that erode a committed release date after the room agrees on it. Your team predicted the erosion on day one. The list just had no way to watch for it.
Give the premortem a pulse
Release Management, Roadmaps & Product Portfolio for Jira treats a premortem’s output the way it treats the team’s confidence vote: as expert judgment worth keeping current, not a snapshot to admire. The confidence vote asks “how sure are we?” The premortem asks “what breaks us?” Both are answered honestly exactly once — on planning day — and both start aging the moment the room empties.
The app keeps them current the same way. Every release carries a committed date paired with a confidence band — the 50%, 85%, and 95% dates from Monte Carlo simulation over the team’s actual Jira throughput. The team still owns every assumption: which throughput window is representative, whose capacity counts, what’s in scope. The app does the arithmetic at a scale no meeting can, and re-does it as reality moves. That turns each premortem finding into a watched signal:
- “Scope will grow mid-release.” The scope baseline set at commitment tracks every addition — and reports the drift it caused, attributed in days.
- “The platform dependency will land late.” Hard and soft dependency links feed the critical path, so a blocker that starts slipping shows up as days of movement on the committed date, not as a surprise in a status meeting.
- “We’re thinner in May than the plan admits.” PTO, public holidays, and availability changes re-forecast the band the moment they’re recorded.
When the committed date falls below its 85% confidence line, the release flags itself — on-track, attention, at-risk — and drift attribution tells you which premortem prediction is coming true, and what it has cost so far in days. It’s the same discipline the planning fallacy demands of the date itself: don’t ask how everyone feels. Look at what the record says.
Renegotiate while it’s still cheap
The point isn’t a prettier warning light. It’s timing. A premortem prediction that comes true in week three — visible as six days of scope-attributed drift — is a renegotiation: trade a should-have below the cut-line, re-sequence around the blocker, or move the date while stakeholders still have options. The same prediction discovered in week ten is an apology. Teams that run premortems already believe failure is cheaper to face early. Watching the committed date’s confidence band between planning days is the release-length version of the same belief.
Run your next premortem. Then give the list somewhere to live. Release Management, Roadmaps & Product Portfolio for Jira keeps every release’s committed date on a live confidence band and attributes every day of drift to the scope, dependency, or capacity change that caused it — so the failure your team imagined stays imaginary. See how it works in the docs.
1 Comment
Leave your reply.