Every two weeks, our engineering team holds a sprint retrospective: what went well, what didn't, and a short list of action items to fix it. We went back through twelve sprints' worth of retro notes — thirty-one action items in total — and checked how many actually happened. The results were not what the format implies they should be.
The number
Of thirty-one action items, 6 were clearly completed, 4 were partially addressed, and 21 simply never came up again — not rejected, not explicitly deprioritized, just absent from every subsequent retro as if they'd never been written down. The retro format produces a tidy list every two weeks. It does not, on its own, produce follow-through.
Why the list disappears
Because the action item gets written at the end of a 50-minute meeting, in the last five minutes, by someone tired of talking about the problem and ready to move on. "We'll add a step to the deploy checklist" gets written on a sticky note, photographed, and pasted into a doc that nobody opens again until the next retro, two weeks later, when a fresh set of problems takes priority over following up on the old ones. The action item was real. The mechanism for tracking it was a photo of a sticky note, which is not a mechanism at all.
The item that comes back every quarter
"Improve test coverage on the billing service" has appeared, in some phrasing, in at least five of the twelve retros we reviewed. Each time, it's treated as a fresh observation rather than a repeat offender, because nobody cross-references this retro's complaints against last quarter's action items — the team re-discovers the same problem, writes the same fix, and loses the same thread, on a loop that the retro format itself has no mechanism for detecting, since each retro only looks backward two weeks, never backward twelve.
Why nobody notices the pattern
Because catching it requires someone to actually read the last five retros before the sixth one starts, and reading five old retro docs is not itself fun, is not itself an agile ritual with a name, and competes for the same thirty minutes everyone would rather spend on the actual sprint work. The retro format excels at surfacing a problem in the moment. It has no native memory of its own history, which means every recurring issue gets treated, repeatedly, as a surprise.
What the retro actually produces
A genuine, valuable release of pressure — a scheduled, structured space where frustration gets voiced, heard, and briefly addressed, which measurably improves team morale even when the specific action items evaporate. The retro's real function may be closer to a pressure valve than a project-tracking tool, and conflating the two — expecting thirty-one sticky notes to become thirty-one completed tickets — is where the format quietly fails to deliver on its own stated promise.
What we're not saying
We're not saying retros are theater — the conversation itself is often the most honest half-hour of the sprint, and venting a real problem out loud, even without a guaranteed fix, has real value for a team's morale and cohesion. We're saying the action items at the end deserve the same rigor as any other backlog item — a ticket, an owner, a due date — rather than a sticky note and a group photo, if the team actually wants the fix rate to look more like six out of thirty-one's opposite.
Our recommendation
Open every retro by reviewing last sprint's action items first, before any new ones get written. It's five extra minutes, and it's the only mechanism that would have caught "improve test coverage on the billing service" showing up for the fifth time instead of the first.
If your last twelve retros also produced more sticky notes than completed fixes, email us at contact@b2bsaas.guru. We'll help you audit them. We already know what we'll find, because we just found it in ours.