Postmortem actions get done when there are few of them, each has a single owner and a date, and the sprint has capacity set aside for them before the next feature plan is drawn up. A long list filed in a wiki after the incident has passed will mostly be forgotten.
Why actions stall
After an incident, energy is high and the list grows fast. Two weeks later the roadmap pressure returns. Actions with no owner or no size sit at the bottom of the backlog, and the same weakness shows up again in a new form.
The fix is not stricter follow-up emails. It is treating the actions as planned work with the same rules as features.
Cut the list to what changes outcomes
For each proposed action, ask: if we had this before the incident, would the impact have been smaller or shorter? Keep the actions that pass. Move the rest into a separate "ideas" list that does not claim to be a commitment.
A good target is three to five actions that you fully intend to finish. Five done beat fifteen promised.
Classify each action
Sort the survivors into three kinds, because they need different handling.
- Prevent: removes the cause, such as rotating a key or closing an exposed service.
- Detect: shortens the time to notice, such as an alert on unusual access.
- Respond: shortens the time to act, such as a runbook or an access path for the on-call engineer.
If the list is all Respond and no Prevent, you are adapting to the problem instead of removing it. That is sometimes right, but make it a choice.
Make each action plannable
Every action needs five fields: a single named owner, a size estimate, a due date, a definition of done, and a link to the incident. "Improve monitoring" is not an action. "Alert when a service account reads more than normal from the customer table, tested with a replay of last week's traffic" is.
Run the size estimate through the same process as other work. If you are unsure how, see estimating security work in story points.
Reserve capacity before planning
Decide how much of the next two sprints belongs to incident actions and subtract it from feature capacity before planning starts. If the actions have to compete with features at planning time, they lose. State the split openly to product partners, along with what it buys: a lower chance of a repeat.
Review in public, briefly
Add a standing two minute item to the team meeting: which incident actions are open, which are late, and why. When an action slips, decide on purpose. Either move the date, split the work, or drop it with a recorded reason. For a deeper look at why good reviews still fail at this step, read the postmortem was good, the actions were not done.
Quick check
How long should we give teams to finish postmortem actions?
There is no universal number. Set dates by size and risk, and keep high-impact prevention work to the next one or two sprints. Reassess anything that slips twice.
Who should own an action that spans teams?
Pick one person who is accountable for the outcome, even if others do the work. Shared ownership usually means no ownership.
Last reviewed: 19 October 2026.
