Why Retrospective Action Items Never Get Done — And How to Actually Fix It

Ask any scrum master how many action items from last sprint's retrospective actually got done. Most pause before answering.

Research puts the average retrospective action item completion rate at 40–50%. That means roughly half of everything a team commits to improving gets quietly dropped before the next session. The team runs another retro, identifies the same problems, commits to the same improvements, and the cycle repeats.

This is not a motivation problem. Most teams genuinely want to improve. The failure is structural — and it comes from three specific places.

The Three Reasons Action Items Fail

1. No real owner

"The team" is not an owner. When an action item is assigned to everyone, it belongs to no one. The implicit assumption is that someone will pick it up — and that assumption is wrong often enough to be a pattern.

Effective action items have a single named person responsible for driving them forward. Not a pair, not a sub-team, not "engineering." One person whose name is on it.

This sounds obvious, but it is consistently skipped in retros. The conversation moves fast, the facilitator wants to keep momentum, and items get logged with soft ownership language that dissolves the moment the call ends.

2. Too many at once

When every idea from a productive retrospective becomes an action item, none of them get done. A list of eight commitments is not a plan — it is a way to feel productive without changing anything.

The constraint that works: three items maximum per sprint, ideally one or two. The team picks the highest-leverage improvements and ignores the rest until next time. Prioritization feels like leaving things behind. In practice, it is the only way anything moves forward.

Teams that limit themselves to fewer items consistently outperform teams with longer lists. The discipline is in the selection, not the execution.

3. They disappear after the session

This is the most underappreciated cause, and the one most tools completely fail to address.

The retrospective ends. Action items get logged in the retro tool — or worse, pasted into a doc, a Notion page, a Slack message — and then no one looks at them again until the next retro. By then, two weeks have passed, priorities have shifted, and half the items are either forgotten or quietly deemed irrelevant.

The items did not fail because the team was lazy. They failed because they had no mechanism to stay visible.

What Actually Fixes It

Specificity first

Vague action items do not get done. "Improve our deployment process" is a project, not an action item. "Set up a staging environment by Friday — owner: Karan" is an action item.

The test: can a new team member read this item and know exactly what done looks like, who is responsible, and when it should be complete? If not, it needs to be rewritten before the retro ends.

This takes two extra minutes per item. It is consistently the highest-return use of time in the entire retrospective.

Review before you add

Most teams review action items at the end of the retro, after an hour of discussion when everyone's energy is low. The items get a quick scan, some get marked done, and the meeting closes.

A more effective pattern: review last sprint's action items at the very start of the session, before any new cards are added. This does two things. It holds the team accountable in a structured way — the review is not a footnote, it is the opening agenda item. And it informs the session itself: if three items are still open, the team knows before they start generating new ones.

The order matters. Status check first, then retrospective.

Items belong to the team, not the session

This is the architectural shift most tools have not made.

When action items are attached to a single retrospective, they live and die with that session. The tool is designed around a meeting, and the meeting is over. Items that were not completed do not naturally carry anywhere — someone has to manually copy them, which means they usually get lost.

The better model: action items belong to the team and persist across sessions. An unresolved item from sprint 14 is still visible in sprint 18. It carries its original context — what sprint it came from, who owns it, how overdue it is. It shows up automatically at the start of the next retro, before the team adds new cards.

This changes the dynamic entirely. The team is not starting fresh each sprint. They are managing a continuous backlog of improvements alongside their delivery work, and the retrospective is a regular checkpoint on that backlog — not a one-time event that resets.

What Good Follow-Through Looks Like

Teams with healthy action item completion rates tend to share a few practices:

The list is short. One to three items per sprint, chosen deliberately, not captured comprehensively.

Every item has a name on it. A single owner, not a group, not a role.

Items are written specifically enough to be actionable. The "done" state is unambiguous before the retro closes.

Unresolved items from previous sprints open the next retro. They are not optional to review — they are the first agenda item.

Completion rate is tracked over time. Teams that measure their follow-through improve it. Teams that do not measure it assume they are doing better than they are.

The last point matters more than it looks. A team that knows their completion rate is 45% has something to improve. A team with no visibility assumes the system is working until the same themes keep resurfacing sprint after sprint.

The Continuity Problem Is a Tool Problem

Most retrospective tools are built around the meeting. They are good at facilitating the session — timers, anonymous cards, voting, grouping. They are not built to hold the team accountable between sessions.

This means the follow-through problem does not get solved by running better retrospectives. It gets solved by changing where action items live and how they surface over time.

When items carry forward automatically, when overdue actions are flagged, when the next retro opens with a clear view of what was committed to last time — completion rates improve not because the team is trying harder, but because the system makes it harder to forget.

Retromate carries unresolved action items forward to every subsequent retro automatically. Items belong to the team, not the session — with original context, owner, and overdue status intact. Free for teams of 5 or fewer.