Key takeaway: The output of an incident review is not the document — it is the small number of changes that actually ship. Producing more items than the team will complete guarantees the important ones are among the abandoned.
Why the Backlog Grows
An incident review generates a list. Add monitoring here, improve a runbook there, refactor that component, add a test, review a configuration. Fourteen items, each individually reasonable.
None are urgent by the time the review happens, because the incident is over. They enter the backlog alongside feature work, get deprioritised in successive planning cycles, and become archaeology.
Six months later a similar incident occurs and the review produces overlapping items. That repetition is the clearest available signal that the process is not functioning.
Fewer Items, Actually Completed
The discipline that works is limiting the count deliberately. Two or three items per incident, each with a named owner and a date, completed before the next planning cycle.
Choosing which two forces the useful conversation: what single change would have prevented this, or reduced its duration most. That question produces better answers than an exhaustive list, because it demands prioritisation rather than enumeration.
| Item type | Value | Frequency in reviews |
|---|---|---|
| Remove the failure mode entirely | Highest | Rare |
| Detect it automatically | High | Common |
| Reduce blast radius | High | Uncommon |
| Improve the runbook | Moderate | Very common |
| Add training or awareness | Low | Common |
Runbook improvements dominate reviews and rank in the middle for value, because they help the next responder without preventing recurrence. They are worth doing and should not consume the whole allocation.
Items that remove the failure mode are rare in reviews precisely because they are harder — they usually require design change rather than an addition. Those are the ones worth the slots.
Tracking Completion Visibly
Put action items in the same tracker as feature work with a distinguishing label, so they compete visibly rather than living in a document nobody reads.
Report completion rate as a metric. A team completing thirty percent of its incident actions is accumulating known risk, and the number makes that visible to whoever sets priorities.
Assign to individuals rather than to teams. An item owned by a team is owned by nobody, and this is the most reliable predictor of an item that will not be completed.
The Cultural Prerequisite
None of this works if reviews assign blame, because people then optimise for minimising exposure rather than for understanding. Reviews that identify human error as a root cause stop the analysis exactly where it becomes useful — the interesting question is why the system permitted a normal mistake to cause an outage.
Focus on the conditions rather than the decision. A deploy that took down production is a story about the absence of a canary stage, not about the person who ran it.
The Bottom Line
Limit each review to two or three action items with individual owners and dates, prioritise changes that remove or detect the failure over runbook additions, track completion rate as a metric, and keep the analysis on system conditions rather than individual decisions.
