Post-Incident Reviews

The meeting after the incident — not the sprint retro stretched to fit. Different format suite, different rituals, different closer.

Why this matters

A post-incident review is not a sprint retrospective and the failure mode is treating it like one. The corpus is dense on the document — Google SRE, Atlassian, incident.io — and almost silent on the hour around the table. That hour is where blamelessness either becomes real or becomes a slogan. Read the Prime Directive aloud at the top. If that feels theatrical, you're not ready to run this meeting. Skip the energizer; opening a post-incident with Two Truths and a Lie is a category error.

Recommended activities

How to run it

Open with the Prime Directive — read, not summarised. Reconstruct the incident with a Timeline Retrospective if multiple people held different parts of the picture; the timeline is the shared artefact. Then run the analysis: Five Whys for a single-cause incident where the chain is the story, Fishbone for multi-cause incidents where the contributing factors fan out — software incidents almost always need the map, not the chain. Use Temperature Check (anonymous) at the midpoint if the room is going quiet; you need to know whether people are processing or shutting down. Close with Dot Voting on the action items so the meeting leaves with a ranked list, not a wall of stickies — and every voted action gets a name and a date attached before anyone leaves the room.