Why Half Your Retro Action Items Never Get Done

RetroTools TeamJune 21, 20265 min read

Your team is probably good at retros. You fill the board, you vote, you leave with a list of things to fix. Then the next sprint swallows everyone whole, the list sits untouched, and two weeks later you write a new one that looks suspiciously like the old one.

That is not a retro problem. It is a follow-through problem, and almost every team has it.

The numbers are grim. Most teams finish fewer than half the action items they commit to. One PMI community poll put it worse, with nearly two thirds of respondents saying they act on under a quarter of the ideas their retros produce. The reflection part works fine. The part where anything actually changes is where it falls apart.

A Retro With No Follow-Through Is Just Venting

Here is the uncomfortable version. A retrospective that surfaces ten good insights and changes nothing is a structured complaint session with a timer.

It is worse than nothing. Every time the team raises a real issue and watches it evaporate, they learn a small lesson: saying things here does not lead anywhere. So next time they say less. The retro gets quieter, blander, safer. People stop bringing up the stuff that matters because they have seen where it goes, which is nowhere.

The good news is that follow-through is a mechanical problem, not a motivational one. You do not need the team to care more. You need fewer items, clearer owners, and somewhere the work can live. We cover the full meeting flow in our guide to running a great retrospective; this is about the bit that happens after everyone logs off.

Why Action Items Die

When an action item doesn't get done, it almost always failed in one of three predictable ways.

Notice that none of these are about effort. They are about setup. A well-formed action item gets done by ordinary people having an ordinary sprint. A badly-formed one would not get done by a team of saints.

Make Them Small, Owned, and Visible

The fix is boring, which is why it works. Three rules:

1. Cap it at one to three per retro. Two changes you actually ship beat ten you abstractly endorse. If everything is a priority, nothing is.
2. Put one name on each. Not "DevOps," not "the team." A person. They do not have to do the work alone, but they own getting it moving.
3. Write it so "done" is obvious. "Add a pre-deploy checklist to the CI pipeline" has a clear finish line. "Be more careful with deploys" does not.

Then the rule that ties it together: if it is not in the sprint, it does not exist. An action item that sits in your retro tool, separate from your real backlog, is competing for attention with nothing and losing. Move it into wherever your team plans real work, give it a slot, and let it fight for time like everything else.

Where Action Items Should Live

There is a genuine argument in the agile world about this. One camp says retro actions belong in Jira alongside feature work so they get the same visibility and grooming. The other says dropping them into a 400-item backlog is how they quietly disappear. Both have a point, and the honest answer depends on how disciplined your backlog already is.

What is not up for debate is that an action item needs a home with an owner, a due date, and a status you can see without going looking.

Some tools are built around exactly this. Sprintlio is the clearest example: it tracks owners, due dates, and completion rates, syncs items to Jira, and pings owners in Slack when something is due. Its whole pitch is accountability, and for a team that keeps dropping the ball it is worth a look. Retrium leans on Jira too, turning retro actions into tracked tickets so they live with the rest of the work.

Others keep the items in the retro tool and push them outward. Kollabe lets you assign owners and due dates and export to Jira, GitHub, or Linear, though it has no cross-retro trend dashboard, so seeing whether a recurring theme is improving over time still falls to you. That is the catch with every tool here: software can store the commitment, but it cannot make the team honor it.

Start There Next Time

You do not need a new format, a facilitation course, or a bigger tool budget. Next retro, before you generate a single new card, pull up last sprint's action items and go through them one by one. Done, not done, why not.

It will be uncomfortable the first time. That discomfort is the entire point. Once people know the list gets read back to them in two weeks, the items get smaller, sharper, and finished. The reflection was never your problem. This is.