Most teams run retros for about three sprints. Then it gets fuzzy. By sprint six, half the team treats it as optional. By sprint twelve, retros are something the new tech lead wants to “revive”.
This isn’t a discipline problem. It’s almost always a structural one. Retros die for predictable reasons, and a small amount of process design keeps them alive indefinitely.
This post is the failure modes we see most often, why they happen, and the moves that keep retros useful enough that the team actually wants to do them.
Failure mode 1: Action items go nowhere
The single biggest killer.
Sprint 1 retro: team raises five issues, picks two action items.
Sprint 2 retro: team raises four issues, picks two action items.
Sprint 3 retro: someone notices nobody did the action items from sprint 1 or 2.
Sprint 4: attendance drops.
The team correctly concludes that talking is cheap. If actions don’t ship, the retro is theatre.
The fix: every action item gets an owner and a deadline that lands inside the next sprint. If you can’t assign one, it’s not an action item — it’s a wish, and wishes don’t go in retros.
The owner doesn’t have to do the work alone. The owner is responsible for getting the work scheduled — usually by adding a ticket to the next sprint, or escalating to whoever can. No owner, no item.
Then: every retro starts by reading the previous retro’s action items aloud. Done? Great. Not done? Why? This 90-second ritual is the single biggest predictor of whether a team’s retros stay alive past sprint six.
Failure mode 2: Same complaints, every sprint
“Standups are too long.” “Tickets aren’t ready when sprint starts.” “We need better testing infrastructure.” Sprint after sprint, the same items.
This is failure mode 1 in disguise — the action items aren’t shipping, so the symptoms keep recurring. But it has a second cause: some problems are too big for a single sprint to fix and the team doesn’t know how to break them down.
The fix: when a complaint shows up two retros in a row, stop the format and ask a different question: what’s the smallest experiment we could run next sprint to make this 10% better? Not solve. Better. By 10%.
“Tests are slow” → “next sprint, two people spend a half-day profiling the slowest 5 specs and we vote on the result.” That’s a sprint-sized action item. “Make tests fast” is not.
Failure mode 3: The tech lead does most of the talking
You can spot this in five minutes. The most senior person identifies the problem, picks the action, names the owner, and the rest of the team nods. Within four sprints the rest of the team is mentally elsewhere.
Retros work because the team surfaces what’s true. The lead’s job in the retro is to ensure that happens — not to be the source of truth.
The fix: silent generation. Five minutes at the start where everyone writes their items on stickies (or in a shared doc), no talking. Then group, then discuss. The lead writes their stickies last and shares them last.
This single change roughly doubles the volume of distinct items raised, and it surfaces things the lead would never have seen because they’re not the one paying the cost.
Failure mode 4: Same format, every sprint
Start/Stop/Continue is a fine retro format. So is Mad/Sad/Glad. So are 4Ls and Sailboat and KALM. The problem isn’t any individual format — it’s running the same format for a year.
After about sprint four, the team’s brain optimises for the format. They start filling buckets, not noticing things. The retro becomes a fill-in-the-blank exercise instead of a thinking exercise.
The fix: rotate the format every 4–6 sprints. We have a retro template generator that gives you five formats with ready-to-paste markdown. The point isn’t that any one is better — it’s that changing the prompts changes what the team notices.
A team that ran Start/Stop/Continue for nine months and switched to Sailboat for one sprint will tell you it felt like a different team showed up.
Failure mode 5: It’s never long enough — or it’s always too long
Two opposite failures with the same root cause: no agreed-upon time budget.
When retros run too short (15 minutes squeezed at the end of sprint review), the team raises problems but never finishes choosing actions. When they run too long (90+ minutes for an 8-person team), people zone out, the back half of the conversation is theatre, and the strongest voices win.
The fix: time-box at 60 minutes for a sprint of two weeks, 30 minutes for one-week sprints. Strict. With a structure that fits inside it:
- 5 min: read previous retro’s action items, mark done/not done
- 10 min: silent generation
- 15 min: cluster + dot-vote on top items
- 20 min: discuss the top 2–3 items only
- 10 min: pick action items with owners and deadlines
If there’s not enough material, end early — the team will love you. If there’s too much, the dot-vote does the prioritisation.
Failure mode 6: No psychological safety
This is the hardest one, because no process change fixes it.
If raising a problem in retro has historically led to subtle penalties — the person being made to fix the thing they raised, or being seen as “negative”, or being the one who held up sprint sign-off — people will stop raising things. The retro will look healthy on the surface and contain none of the actual problems.
The fix: anonymous input until a baseline of trust is built. Stickies (physical) or a shared doc with no names. The lead’s only job for the next four retros is to demonstrate, in public, that raising hard things gets them addressed without penalty.
This rebuild takes months, not sprints. Don’t try to skip it with a clever format.
Failure mode 7: The retro happens after sprint review
This sounds minor and isn’t. By the time sprint review is done, half the team is mentally on the next sprint. They came in motivated to demo their work; now they’re being asked to look backward.
The fix: schedule retro on a different day, or at minimum with a 30-minute break in between. Even better: the morning before sprint planning, so action items can be turned into sprint tickets the same day.
What to do if retros are already dead
Don’t try to revive the old retro format. The team has trained itself to associate the format with going through the motions.
Run a single retrospective with one question, on a fresh format the team has never used:
“If we changed one thing about how we work next sprint, what would have the biggest impact?”
Silent generation, dot-vote, pick one. Owner + deadline. Done in 30 minutes.
Then ship it. If you ship the result of that retro and the team sees it land, you’ve earned the right to run a second one. Skip the ceremony, deliver the change, build back from there.
The bottom line
Retros don’t die because teams stop caring. They die because:
- Actions don’t ship → conversations feel pointless
- Same items recur → the format isn’t surfacing root causes
- The lead does most of the work → the team disengages
- Same format forever → the format optimises out the noticing
- No time budget → the meeting either ends in chaos or drags
- No safety → the real problems never come up
- Retro is a postscript to review → exhausted team looking backward
Fix any one of these and retros get useful. Fix three and they become the most valuable hour of the sprint.
The fastest path is owners + deadlines + a 90-second review of last sprint’s actions at the start of every retro. That alone will keep most retros alive for years.
SprintFlint has native retrospectives built in — every sprint gets a retro module with action item tracking that rolls forward. Want to try it? Start free — 300 tickets, no card.