Nisha closes the retro the same way she always does—marker in hand, half-smile on her face, trying to sound hopeful even when everyone looks a little tired.
Okay… what actions should we take next sprint?

At first, the team perks up. People sit forward. Someone says, “We should definitely fix this.” Another person nods like they’ve been waiting all week to finally say it out loud. The energy spikes just enough to feel like progress.

• Improve testing earlier
• Reduce interruptions
• Clarify requirements sooner
• Document deployment steps

Someone dutifully turns the bullets into Jira tickets. They get a label like retro-action and a due date that feels optimistic. Everyone leaves the call with that warm sense of closure—like the mess has been handled because it’s been named.

Three months later, Nisha is cleaning up old boards and opens a retro from last quarter. The action items stare back at her. Not similar. Not “same vibe.” Identical word for word, like a ghost copied and pasted them. For a second she wonders if she opened the wrong board… and then she remembers: nobody ever looked at those tickets again.

If this feels uncomfortably familiar, it’s because it’s basically universal. Almost every Agile team has a trail of repeated action items, forgotten improvements, retro Jira tickets nobody checks, “we’ll do this next sprint” promises, and the same problems showing up again like clockwork.

This isn’t a facilitation failure or a “your team lacks discipline” problem. It’s a pattern and this article is about why action items die: the psychological relief they provide, the organizational dynamics that quietly kill them, and the ways teams learn to stop expecting change.

The pattern is backed by hard data. Research shows that 40% of retrospective action items are never completed, 65% of teams generate insights they never act on, and 70–80% of meaningful action items never get implemented (Questworks; Kollabe; Majkic). In one recent study, 69% of agile teams implemented less than 60% of their retrospective actions (Easy Agile, 2026).

The Emotional Relief Trap

Retrospectives are supposed to create change, but they often create something else first: emotional relief. You finally get to say the thing that’s been grinding you down all sprint. You hear other people say, “Yes, that happened to me too,” and suddenly you’re not alone in it.

Even Esther Derby and Diana Larsen’s foundational Agile Retrospectives: Making Good Teams Great (2006)—with its five-phase framework for continuous improvement—can’t protect a team from this: the emotional relief trap can undermine even the most well-structured retro.

That relief is real and it’s also dangerous. The team walks away thinking, At least we talked about it. The pressure drops. The nervous system unclenches. And because the discomfort is gone, the urgency goes with it.

Talking can feel like doing. Naming the problem can feel like solving it. A retro can give you the sensation of progress without any of the cost of change, no awkward conversations, no trade-offs, no escalation, no risk.

Over time, retrospectives can accidentally become a ritual that produces the illusion of improvement. The team gets better at describing the pain, better at agreeing it’s real, better at writing it down… and worse at actually changing the conditions that created it.

Action Items Without Ownership

Most retro action items die for a boring reason: nobody owns them. Everyone agrees they’re important. Everyone assumes someone else will pick them up. And because the team is full of capable, well-intentioned people, it feels safe to leave it vague.

Psychologists call this Diffusion of Responsibility. When responsibility is shared across a group, individuals feel less accountable to act. It’s not laziness, it’s human wiring. The bigger the “we,” the smaller the “me.”

It’s also backed by classic social psychology. Latané and Darley (1968) demonstrated that people are dramatically less likely to help when others are present. In their landmark experiments, subjects who believed many others were also hearing a staged emergency were slower and less likely to intervene than those who believed they were alone.

The mere presence of others reduces personal responsibility and in retrospectives, when “the team” owns an action, nobody does.

So the action item becomes a communal wish. It lives in Jira with no real sponsor, no time carved out, no trade-off made, and no consequence for ignoring it. When everyone is responsible, no one is responsible—and the graveyard gets another headstone.

Teams Choosing Safe Actions

Even when teams do create action items, they often choose the ones that feel safe. Not because they’re cowardly—because real systemic issues can feel like stepping into traffic. If the root cause touches leadership, staffing, incentives, or cross-team politics, it’s easier to pick something that sounds productive but won’t upset anyone.

Safe actions are attractive because they’re socially acceptable and emotionally manageable. They don’t require permission. They don’t require conflict. They don’t require anyone with power to change their behavior. They mostly require the team to try harder, be nicer, and write more things down.

Safe actions teams create

• Improve communication
• Sync earlier
• Document better

Real issues teams avoid

• Challenging leadership pressure that forces rushed work
• Fixing staffing and workload mismatches
• Escalating dependency chaos across teams and priorities

Research reveals why: 29% of retrospective actions require changes outside the team’s control, and 21% never get prioritized in sprint planning (Easy Agile). Teams learn—often unconsciously—to propose actions that won’t require escalation, won’t challenge authority, and won’t force uncomfortable conversations. The action items become a performance of improvement rather than a path to it.

The tragedy is that safe actions can be genuinely good ideas—and still be irrelevant to the real problem. They become a way to stay busy while staying stuck. And after a few sprints, the team quietly learns which truths are allowed in the retro and which ones are too expensive to say out loud.

When Teams Stop Believing

After enough repeats, something shifts. The team stops being surprised that nothing changes. They still show up, still fill out the board, still nod at the same themes—but the energy is different. It’s flatter. More resigned.

This is where learned helplessness shows up. Martin Seligman’s research described how, after repeated experiences where actions don’t change outcomes, people stop trying—even when change becomes possible. Not because they don’t care, but because hope starts to feel irrational.

In Seligman’s classic experiments, dogs exposed to inescapable shocks later failed to escape even when escape became easy—they simply lay down and accepted the pain. Around two-thirds of the dogs that previously had no control failed to escape at all (Seligman & Maier, 1967; later reviews in PMC). The critical insight: they hadn’t learned to be helpless; they had learned that their actions didn’t matter. The same pattern emerges in teams: after enough retrospectives where actions die, people stop believing their input will change anything.

In teams, it sounds like: “We’ve raised this before.” “Nothing will happen.” “That’s just how it is here.” The retro becomes less about improvement and more about emotional venting with a timestamp.

Eventually the process turns performative. You go through the motions because it’s on the calendar, because Agile says you should, because it looks responsible. But underneath it, the team has stopped believing the organization will pay the price of fixing what the retro keeps revealing.

The NASA Parallel

There’s a darker parallel here that’s worth naming. Before the Challenger disaster, engineers repeatedly raised concerns about the O-rings in cold temperatures. The warnings existed. The information existed. The conversations happened.

What didn’t happen was action at the level required. The problem wasn’t a lack of retrospectives or a lack of smart people—it was normalization of deviance: the slow process where repeated anomalies become accepted as “normal” because nothing catastrophic has happened yet.

Diane Vaughan, in her landmark study The Challenger Launch Decision (1996), called this normalization of deviance—the gradual acceptance of rule-breaking or risk-increasing behavior as normal when no immediate catastrophe happens. At NASA, repeated observations of O-ring damage were gradually redefined as acceptable risk. Production pressure, structural secrecy, and a culture that explained away unwanted test results created a system where warnings existed but action didn’t (Vaughan, 1996).

That maps uncomfortably well to teams who keep surfacing the same issues sprint after sprint. The interruptions, the unclear requirements, the brittle deployments—each one becomes a tolerated defect in the system. You learn to work around it. You stop expecting it to be fixed. And the retro becomes a record of what you’ve normalized.

The Data Tells the Story

One longitudinal study of a single project found 109 issues raised but only 36 action items created—an early sign of the bottleneck: teams can name problems faster than they can convert them into commitments (SINTEF).

And even when actions do get created, follow-through is inconsistent. One reported team-level implementation rate is 75%, but it varies widely by environment and study (IJRAR). The problem isn’t awareness—teams often rely on subjective input rather than data-driven signals, even though objective project data is available and rarely used systematically (CHUniversiteit; arXiv).

So the retrospective process isn’t “broken” in the mechanical sense. It’s doing what it’s designed to do: reveal reality. What’s broken is the organizational willingness to act on what it reveals.

What Actually Needs to Change

If you’re hoping the answer is “better action item templates” or “a stronger retro format,” you’re going to be disappointed. Those can help at the margins, but they don’t solve the core issue. The core issue is whether the organization is willing to act on uncomfortable truths.

Real change requires leadership accountability not in the abstract, but in the specific. When a retro surfaces a systemic problem, someone with authority has to own the response, fund the fix, and accept the trade-offs. Otherwise the team is being asked to solve structural problems with sticky notes.

Systems thinker Donella Meadows identified 12 leverage points for intervening in complex systems, ranked from weakest to strongest. Most teams focus on the weakest: adjusting parameters, tweaking processes, adding more meetings. But Meadows showed that the most powerful leverage points involve changing information flows, rules, goals, and ultimately, the paradigms that shape how the system operates (Donella Meadows, Thinking in Systems). Retrospective action items die because teams are trying to fix systemic problems with low-leverage interventions.

It also requires psychological safety, because the real issues are often the ones people are afraid to say plainly. If naming the root cause risks punishment, career damage, or being labeled “negative,” the team will keep choosing safe actions. They’ll keep polishing the edges of a system they’re not allowed to redesign.

And finally, it requires systemic change: adjusting incentives, reducing overload, clarifying decision-making, fixing dependencies, and making space for improvement work that doesn’t ship features. Until the system changes, the retro will keep producing the same output because it’s accurately reflecting the same input conditions.

The retro action item graveyard isn’t a sign that your team doesn’t care. It’s a sign that your team has been trying to care inside a system that rewards delivery over repair, agreement over ownership, and comfort over truth.

If you want different action items, you need different consequences—and different support for acting on what the retro reveals. Otherwise you’ll keep finding the same tickets, the same promises, and the same ghosts in your backlog.

The most dangerous retrospective isn’t the one where nothing gets written down. It’s the one where everything gets written down and nothing changes.

References

Derby, E., & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.

Easy Agile. (2026). Retrospective Action Items Research Study.

Latané, B., & Darley, J. M. (1968). Bystander intervention in emergencies: Diffusion of responsibility. Journal of Personality and Social Psychology.

Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.

Seligman, M. E. P., & Maier, S. F. (1967). Failure to escape traumatic shock. Journal of Experimental Psychology.

Vaughan, D. (1996). The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press.