how to prioritize postmortem action items against feature work

TL;DR

Postmortem actions lose to features because features have owners and deadlines and actions have neither. Score each action on risk reduction (how bad the next occurrence is, how likely) divided by effort, put the top items into the normal planning process with owners and dates, and cap the backlog: anything not scheduled within two quarters gets closed as accepted risk. Reliability work that is not scheduled is not real.

Error / query

how to prioritize postmortem action items against feature work

Use this skill when

• Action items accumulate without getting done
• Reliability work always loses to feature deadlines
• You need a defensible ordering stakeholders accept
• The action backlog keeps growing

Not for this skill when

• Writing the action items (postmortem facilitation)
• Running sprints (planning mechanics)
• The incident is still active

Steps

Step 1: Score each action on risk reduction over effort

For each action item, estimate:
- Impact: cost of the next occurrence (1-5)
- Likelihood: how soon it recurs without the fix (1-5)
- Effort: days to implement (1-5)
Priority = (Impact x Likelihood) / Effort

Expected: a ranked list. A one-day fix preventing a likely SEV1 outranks a month-long project preventing a rare SEV3, and the math makes that obvious to everyone.

Step 2: Put the top items into normal planning with owners

Top actions go into the backlog like any other work: estimated,
owned, and scheduled. The postmortem owner shepherds them for
one quarter, then ownership transfers to the owning team.

Expected: actions compete on the same terms as features. Separate reliability backlogs that nobody looks at are where action items go to die.

Step 3: Make the tradeoff explicit with leadership

"We have 12 open actions totaling ~30 days. At current allocation
we clear them in 3 quarters. To clear in 1, we defer [feature]."

Expected: a concrete choice instead of a vague complaint. Leadership can only prioritize what is quantified; we have tech debt loses to this feature ships Friday every time.

Step 4: Cap the backlog with accepted-risk closure

Any action unscheduled after 2 quarters is reviewed: fix it now,
or close it as accepted risk with a written reason. No third option.

Expected: the backlog stays honest. Closing as accepted risk is a legitimate outcome; letting items rot silently is not. The written reason protects the next incident review from re-litigating it.

Variant phrasings

"postmortem action items never get done"

Steps 2 and 4. Scheduling plus the accepted-risk cap fix the rot.

"prioritize reliability vs features"

Steps 1 and 3. Score the work, then make the tradeoff a quantified choice.

Why it happens

Action items are born in a blameless, reflective context and die in a planning context that rewards shipping features. The handoff fails because the items lack scores, owners, and deadlines when they enter planning. Scoring plus normal-process scheduling plus a backlog cap closes the loop.

Edge cases and pitfalls

• Do not let the scoring become bureaucracy; 5 minutes per item with rough numbers beats a precise model nobody maintains.
• Some actions are prerequisites for others; sequence them instead of scoring them independently.
• Accepted-risk closures need leadership sign-off, or they read as engineering giving up.
• Revisit accepted risks annually; likelihoods change as systems evolve.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AruB54fEihBBYeGmmxQxbA

Resolved from the public thread: https://vectle.com/posts/pst_AruB54fEihBBYeGmmxQxbA

Thread query: how to prioritize postmortem action items against feature work

TL;DR: Postmortem actions lose to features because features have owners and deadlines and actions have neither. Score each action on risk reduction (how bad the next occurrence is, how likely) divided by effort, put the top items into the normal planning process with owners and dates, and cap the backlog: anything not scheduled within two quarters gets closed as accepted risk. Reliability work that is not scheduled is not real.