Postmortem Action Items That Actually Get Shipped

Two-thirds of postmortem action items never ship. The discipline that gets that number from 35% to 80% has nothing to do with the postmortem itself.

Why action items rot

The retro happens; the action items get added to a tracking doc; everyone returns to feature work. By the next sprint nobody remembers; by the next quarter the doc is forgotten; by the next year the same incident recurs. The rot is structural, not cultural.

The structural failure has three layers. (1) The retro is a one-time event; the action items live in a separate document that nobody opens between retros. (2) The action items don't compete with feature work for capacity; they're "extra" work that always loses to "real" work. (3) Owners don't have a forcing function, no standup mentions, no due dates that get tracked, no consequence to missing them.

The fix isn't about discipline; it's about plumbing. Plumb action items into the team's existing workflow (sprint planning, standups, backlog), give them owners and due dates, and have the EM do a 30-day check. The plumbing is what produces the shipping; "more discipline" is a non-fix.

Four conditions for shipping

• The item has a single named owner (not "the team").
• It is sized small enough to ship in one sprint.
• It is on the team's backlog with priority, not in a separate "tech debt" doc.
• The owner reports status at the next standup until done.

Miss any one of these and shipping odds drop sharply. Each condition addresses one of the structural failure modes. Single owner addresses ownership diffusion. Small size addresses scope creep. On-the-backlog addresses competition with feature work. Standup reporting addresses the visibility gap between retros.

The four conditions are AND, not OR. An item with three of four conditions has shipping odds around 30%; an item with all four is 70-80%. Most teams that struggle with action-item completion fail one of the four; identifying which one is the work.

Owner, not assignee

"Assignee" implies the work is theirs only. "Owner" implies they decide who does the work and ensure it lands. The owner can delegate; the owner cannot assume someone else will pick it up. The semantic difference produces a behaviour difference.

The owner's responsibilities. Decide whether to do the work themselves or delegate. If delegating, find the right person and confirm they'll do it. Track progress. Escalate when blocked. Update the action-items list with status. Close the loop when done. Each is small; the cumulative effect is reliable shipping.

The selection of the owner. Default to the engineer most affected by the incident, they have the highest motivation to fix the system that bit them. If that engineer is overloaded, the EM negotiates: trade some current sprint work for the action item, or assign a different owner. The negotiation is what makes the action item a real commitment rather than a wishlist entry.

Sized to ship in a sprint

"Add comprehensive observability across all services" never ships. "Add a single Prometheus alert for queue-depth > 100k on the ingest service" ships in a day. Slice the action items until they are small enough to be ego-free.

The slicing test. If the action item can be summarised in a Jira ticket title, it's the right size. If the title would have to be paragraph-length, the item is too big. Slice it.

The first slice produces a "what about the rest?" anxiety. "We sliced 'comprehensive observability' down to 'one alert', but what about all the other observability work?" The answer: the other observability work is its own roadmap; this retro produced one specific improvement. Trying to fit "all the observability work" into a retro action item produces an item that won't ship; producing the one specific improvement is what creates compounding change.

On the on-call backlog

The next on-call shift's "between pages" work IS the postmortem action items. Not separate. Not optional. The team that keeps a clean on-call backlog has a queue of small reliability work; the team that doesn't has a tech-debt graveyard.

The mechanism. When an action item is created, it goes onto the team's backlog with a tag (e.g., "post-incident-action"). The next on-call shift's job description includes "work the post-incident-action queue between pages." Each shift, the on-call closes 1-3 items; over a quarter, the team ships 30-50 small reliability improvements.

The benefit compounds. Reliability work that's "free" engineering time (small items + on-call between-pages capacity) ships steadily without competing with feature work. The team's reliability improves quietly while feature delivery continues. Six months in, the on-call rotation is calmer because the reliability work has reduced page volume; the engineers are happier; recruitment improves; the cycle reinforces.

Quarterly lookback

Once a quarter, sum: retros held, action items created, action items closed. Healthy ratio is 70-80% closed within 60 days. Below 50% means the system is broken; above 90% probably means action items are too small to matter.

The metric is a calibration signal, not a performance metric. Below 50% means the team is producing action items it can't ship, the retros are too aspirational, or the team is overloaded, or the EM isn't sponsoring the work. Above 90% sounds great but usually means the action items are too small to produce real change. The healthy range is 70-80%.

What to do with the metric. The quarterly review surfaces the trend; the team adjusts. If the closed rate is dropping, sliced items finer or sponsor a sprint dedicated to the backlog. If it's rising too high, push for slightly larger items that produce more impact per ship. The metric is dialled, not optimised.

Antipatterns

The "owned by the team" item. No name; no shipping. The team that "owns" something owns nothing collectively. Always pick a single name.

The "as time permits" deadline. No deadline; no shipping. Even a soft deadline (end of next sprint) creates more momentum than no deadline. The hard deadline lets the EM track progress; without it, the item drifts.

The "tech debt" sidetrack. Action items get filed in a "tech debt" backlog separate from the team's main backlog. Tech-debt backlogs are graveyards. The action item belongs on the main backlog, competing with feature work, and getting prioritised normally.

The "we'll talk about it next retro" deferral. Items defer until the next retro; the next retro defers them again; six months later they're still on the list. If an item can't be shipped within a sprint, it's the wrong item, slice or kill it.

Visibility mechanisms

The owner reports at standup until the item is done. "I'm working on the auth-runbook update; I'll have it in PR review by Thursday." 30 seconds, every standup, until shipped. The visibility forces progress.

The action-items list lives in the team's main project board, with the same status flow as feature work (To Do, In Progress, In Review, Done). The unification is what removes the second-class-citizen treatment that "tech debt" backlogs traditionally get.

The EM reviews open action items in their weekly 1:1s with owners. Not every item every week, the EM picks 1-2 to discuss based on age and importance. The conversation is "what's blocking this from shipping?", almost always the answer reveals a structural issue (priority conflict, dependency, scope confusion) that the EM can clear.

What to do this week

Three moves. (1) Audit your team's last 10 action items. How many shipped within 30 days? The number is your starting baseline. (2) For any item that didn't ship, ask the four-conditions question, which condition was missing? The pattern reveals where to invest. (3) Move open action items onto the main backlog (not a separate doc). The single move usually doubles completion rates within a quarter.