Why 2/3 of Retrospective Action Items Die (And How to Fix It)

The Graveyard Shift

Picture this: It's sprint retrospective time. The team gathers, either in person or scattered across video tiles. Sticky notes fly. Someone brings up the deployment bottleneck that's been killing velocity. Another person mentions the flaky test suite. A third suggests pair programming rotations to spread knowledge.

By the end of the session, you've got a tidy list of action items:

• "Investigate CI parallelization" — assigned to Sarah
• "Document the authentication flow" — assigned to Mike
• "Set up rotation schedule for code reviews" — assigned to the team lead

Everyone nods. The retro ends. People feel good. Progress was made.

Two weeks later, same room, same faces. New retro. And nobody mentions what happened to those action items. Because nothing happened to those action items. They died quietly, somewhere between the Jira backlog and everyone's good intentions.

Sound familiar?

The Uncomfortable Math

Here's a stat that should haunt every scrum master: A PMI community poll found that nearly two-thirds of teams implemented fewer than 25% of the improvement ideas from their last retrospective. Not a single respondent said they implemented more than 75%.

Read that again. Two-thirds of teams can't even execute a quarter of what they committed to.

This isn't a minor process inefficiency. It's a massive credibility crisis. Every abandoned action item is a small broken promise. Stack enough of those up and you get "retrospective fatigue" — that cynical, checked-out vibe where people stop bothering to raise issues because they've learned that nothing ever changes anyway.

The ceremony continues. The improvement doesn't.

Why Do Retrospective Action Items Die?

Retrospective action items die because the system is designed for failure, not because people are lazy or don't care. Nothing forces the team to confront old commitments, "in progress" states hide abandonment, forgotten items vanish without a decision, and admitting a broken promise is uncomfortable enough that nobody brings it up. Four problems, one graveyard.

Problem 1: No Forcing Function

Traditional action items live in Jira or a shared doc or someone's notes. They compete with actual sprint work for attention. And guess what wins when the product owner is asking about that feature deadline? Not "investigate CI parallelization."

There's no moment where the team is forced to confront the fate of previous commitments. The retro focuses on what happened this sprint, not what we promised last sprint.

Problem 2: Progress Theater

Many tools let you mark action items as "in progress" or "50% complete" or whatever percentage makes you feel productive. This is a trap. An action item that's been "in progress" for three sprints isn't in progress. It's abandoned with extra steps.

Progress theater lets teams avoid the uncomfortable binary: Did we do this or not?

Problem 3: Quiet Forgetting

The most common fate for an action item isn't completion or explicit closure. It's simply being forgotten. It slides off the bottom of the list, replaced by newer, shinier commitments. Nobody says "we're not going to do this." It just... stops existing.

This is death by neglect, and it's far more common than explicit failure.

Problem 4: Shame Avoidance

Let's be real: admitting you didn't do something you committed to is uncomfortable. Human nature is to avoid that conversation. So we don't bring up the old action items. We focus on the new problems. The cycle continues.

The Annoyingly Effective Solution

When we built the action item system in Simyl Flow, we designed it to be intentionally uncomfortable. Not cruel — just honest. Here's what that looks like:

The Accountability Check

The accountability check is a forcing function: you can't start a new retrospective without first dealing with your old commitments.

When you open a new retro, before you see the board, before anyone adds a single card, a dialog appears. It shows every open action item from previous retrospectives. For each one, you have exactly three choices:

1. Mark Done — You did it. Celebrate. Move on.
2. Carry Forward — You didn't do it, but you still want to. It transfers to this retro with a counter.
3. Won't Do — You're consciously deciding not to do this. You have to say why.

No fourth option. No "in progress." No "let's talk about it later." You must decide.

type ActionDecision = "done" | "carry_forward" | "wont_do" | null;

That's it. Three states. Binary outcomes with an escape hatch that requires explanation.

The Counter of Shame

Here's where it gets interesting. When you carry an action forward, we increment a counter.

This counter is visible. When an action item shows "Carried forward 2x" in that amber badge, everyone can see it. It's not hidden metadata. It's a public signal that says "we've punted on this commitment twice now."

Is this a little uncomfortable? Yes. That's the point. The discomfort creates pressure to either do the thing or consciously decide not to do it. Both are legitimate outcomes. Quiet neglect is not.

We've seen teams where an action hitting "Carried forward 3x" triggers an automatic discussion: "Okay, this keeps getting punted. Do we actually want to do this, or should we just close it?"

That conversation is progress. That conversation almost never happens without the visible counter.

Won't Do Is a Feature, Not a Failure

Most tools treat closing an action item as completing it. We explicitly separate the two.

When you close something as "won't do," you have to provide a reason. "No longer relevant" is fine. "Priorities changed" is fine. "We realized this was a dumb idea" is fine. But you have to articulate it.

This isn't bureaucratic box-checking. It's forcing the team to make an explicit decision. Conscious closure is infinitely better than unconscious abandonment. A decision not to do something is still a decision. A decision creates learning ("we tried to commit to X but couldn't follow through because of Y").

Forgetting creates nothing.

Done or Not Done

We deliberately didn't implement percentage completion or progress states. An action item is either open or done. That's the data model:

export type ActionItemStatus = "open" | "done"; // Simplified - done or not done

This was a conscious design choice that makes some people uncomfortable. "What if I'm halfway through?" Then it's open. "What if I've started the research?" Open. "What if I've written a draft?" Still open.

The only question that matters: Did you do the thing you committed to?

This binary framing eliminates progress theater entirely. There's no comfortable middle ground where you can claim credit for intentions. You either shipped it or you didn't.

Your Actions Follow You

We built a personal dashboard — the "My Actions" page — that aggregates all your action items across every team you're on.

This creates a personal accountability surface. Your commitments aren't scattered across different retro boards and team Jira projects. They're all in one place, staring at you.

The psychological effect is subtle but real. When your open actions are visible in your personal dashboard every time you log in, they're harder to forget. They're not buried in a team backlog. They're in your face.

Trust Is Measured, Not Assumed

Here's where the system gets serious. Action item completion rate feeds directly into our Team Dynamics metrics — specifically, the Trust Score.

function calculateActionScore(
  completed: number,
  total: number,
  config: TeamDynamicsConfig,
): number {
  if (total === 0) return 50; // No actions = neutral
  const rate = completed / total;

  // Use config threshold
  if (rate >= config.healthyActionItemCompletion) return 100;
  if (rate >= config.healthyActionItemCompletion * 0.7) return 70;
  return Math.max(20, rate * 100);
}

Why does action completion map to trust? Because follow-through is trust. When a team consistently delivers on its commitments — even the internal ones that only affect the team — that builds confidence. Conversely, a pattern of broken promises (even small ones like retro action items) erodes the team's trust in itself.

A team that can't trust its own commitments will struggle with everything else.

The metric isn't punitive. A team that creates no action items gets a neutral score. A team that creates a few and completes most gets rewarded. A team that creates many and completes few gets flagged — not as "bad" but as a signal that something's off. Maybe the actions are too ambitious. Maybe there's no time carved out for improvement work. Maybe the problem is systemic.

The metric creates the conversation. The team decides what to do about it.

The Philosophy

Everything we built here stems from a simple belief: explicit decisions beat implicit neglect.

• Saying "we won't do this" is better than quietly forgetting.
• Saying "we're carrying this forward" is better than pretending we didn't commit.
• Saying "we did it" (when you actually did) is better than "we made some progress."

We're not trying to shame teams. We're trying to create a system where honesty is easier than avoidance. Where the path of least resistance leads to clarity rather than ambiguity.

Traditional tools make it easy to forget and uncomfortable to confront. We flipped it. Our system makes forgetting impossible (the accountability check) and confrontation manageable (three clear options, each legitimate).

The result isn't 100% completion rates. That would be unrealistic and probably indicate teams are only committing to safe, easy actions. The result is teams that know the fate of every commitment they made. That's a very different thing, and it's far more valuable.

What We've Seen

Teams using the accountability check pattern report a few consistent changes:

Fewer, Better Actions

When you know you'll be confronted with your commitments, you make fewer of them. But the ones you make are more likely to be things you'll actually do. The "let's put this on the action items list to make people feel heard" pattern dies fast.

Faster Won't Do Decisions

Teams get better at recognizing when something isn't going to happen. Rather than letting it linger for three sprints, they'll close it in one or two. "We said we'd do this, we haven't, we're not going to — let's close it and stop pretending."

More Trust Conversations

When the Team Dynamics score reflects action item follow-through, it becomes data for the retrospective itself. "Our trust score dropped this sprint. One factor: we only completed 2 of 7 action items. What's going on?"

That meta-conversation about the team's ability to deliver on commitments is often more valuable than any single action item.

Try Being Uncomfortable

If your retro action items keep dying, the problem isn't motivation. It's system design. You need:

1. A forcing function — Something that makes confronting old commitments mandatory, not optional.
2. Binary outcomes — Done or not done. No hiding behind percentages.
3. Visible carry-forward tracking — A counter that makes repeated punting visible.
4. Legitimate closure — A "won't do" option that requires a reason but is treated as valid.
5. Personal accountability surfaces — Your commitments follow you, not just the team.
6. Metrics that reflect reality — Follow-through affects team health scores.

We built all of this into Simyl Flow because we got tired of watching good improvement ideas die in the space between meetings. The accountability check is a little annoying. The carry-forward counter is a little uncomfortable. The binary status is a little rigid.

That's the point. Comfort is how action items die.

Sources

1. Bondale, K. (2022). "Why hold retrospectives if ideas don't get implemented?" — PMI "Easy in theory, difficult in practice" blog
2. Wolpers, S. (2024). "Ditch the Unfinished Action Items – How to Make Retrospectives Lead to Real Change"