The Biggest Problem Agile Teams Have with Retrospectives (and How to Fix It)

This post first appeared on our old blog in 2021 (by Ben Staples). We've rewritten and updated it for 2026.

The problem teams complain about most is that retrospectives take too long. The problem that does the most damage is that nothing changes afterward. In 2021, when we asked teams about their biggest retro problem, the most common answer was the length of the meeting. Five years and several vendor surveys later, the clearer answer is follow-through: teams agree on actions and then don't do them. Long meetings, skipped retros and fuzzy memories are often symptoms of that.

This post covers all four problems, with a concrete fix for each.

What teams told us in 2021

Ben Staples, who wrote the original version of this post, ran an informal LinkedIn poll in 2021 asking what the biggest pain point in retrospectives was. We don't know the sample size, so read it as a signal, not a study. The top answers:

The 2021 post listed three problems but only covered two; it never got to "not enough retrospectives". Here are all three, then the one we'd put first today.

Problem 1: The retro takes too long

Some teams really do hold two- or three-hour retros. More often the meeting just feels too long compared with what the team gets out of it. Both usually have the same causes:

For scale, the Scrum Guide caps the retrospective at three hours for a one-month sprint and says shorter sprints usually need less. For a two-week sprint, 45 to 60 minutes is common.

Fix: shorten the meeting, and protect what matters

Vote before you discuss. Group related notes, give everyone three dot votes, and discuss only the top three groups. Everything else stays on the board for anyone who wants to follow up.

Use a timer to protect the part your team values most. Teams get different things out of a retro:

• Hearing new ideas, especially from quieter people who don't get room in the normal flow of work
• Venting, in a healthy way, about something frustrating. If this is what your team needs, a format like Mad Sad Glad gives it a column of its own
• Agreeing on action items with a clear owner and a definition of done for each
• Team bonding, which on some teams happens in the first ten minutes and has nothing to do with the sprint

Pick the one your team values most and give it a fixed block. Say your team gets the most from action items, and agreeing on them takes 15 minutes. Set the timer for discussion to end 15 minutes before the meeting does, and when it goes off, discussion stops, even mid-topic. In Retro Rabbit, Set Timer runs a countdown everyone on the board can see.

Collect notes before the meeting. This is the biggest time saver, and it's the same fix as Problem 3. When notes arrive during the sprint, the meeting can start at grouping and voting.

Here's a 30-minute retro for a two-week sprint when notes were added during the sprint:

Problem 2: Not enough retrospectives

"Not enough retros" usually means one of two things. Either retros get cancelled when the sprint is busy, or they happen so rarely (once a quarter, or only at the end of a project) that the details are gone and the lessons arrive too late to use.

Both are common. In Retrium's 2017 survey of 277 people (Retrium is a retro tool vendor), more than one in five said their team doesn't want to hold retros or their organization doesn't support them.

Fix: make it fixed, small and hard to skip

Problem 3: Nobody remembers what happened

This is recency bias. By the end of a two-week sprint, people remember last Thursday in detail and the first week barely at all. The retro ends up being about the last three days, and the team fixes the wrong things.

You can see it on the board. Compare notes written from memory on retro day with notes written when it happened:

The second set is specific enough to act on, and it includes a first-week win nobody would have remembered.

Fix: write it down when it happens

• Open the board on day one. Keep the next retro's board open from the moment the last retro ends, and ask for a note the day something goes well or badly.
• Ask for very little. One note a week per person beats a promise to "add stuff before the retro". Give triggers: when you're blocked, when something breaks, when someone helps you.
• Bring shared facts. Before the meeting, the facilitator adds what everyone should see: whether the sprint goal was met, incidents, releases. Esther Derby lists "no shared data" among her eight reasons retrospectives fail.
• Pick a format with a learning column. What Went Well and 4Ls both ask what you learned, which rewards notes written in the moment.
• Make adding a note easy. In Retro Rabbit, clicking Start New Retro closes the current retro and opens the next board straight away. People add notes on the board, in the Team Room's Quick Notes box, or with /retro your note if you've connected Slack.

The 2026 view: the biggest problem is follow-through

If we wrote this post from scratch today, this is the problem we'd lead with. The data has caught up with what Scrum Masters have said for years: teams agree on good actions and then don't do them. Easy Agile, a tool vendor, surveyed 419 engineers, product managers and project managers for its State of Team Alignment 2026 report:

In Retrium's 2017 survey, only 33% of respondents named better follow-through on the previous sprint's action items as a benefit of their retros, far behind improved communication (85%) and trust (65%).

Both are vendor surveys, so treat the exact numbers with care. But they point the same way, and they explain the other three problems. When nothing changes, the meeting feels too long, it's the first to be cancelled, and people stop bothering to write anything down.

Fix: close the loop every sprint

1. Open every retro with last retro's actions. Five minutes. Mark each one done, in progress, or dropped on purpose. If nothing got done, that's your first topic.
2. Agree on one to three actions. Derby recommends choosing one or two, and the Agile Alliance notes that one or two improvement ideas per iteration may be enough.
3. Give each one an owner, a verb and a date. "Fix staging" becomes "Marcus writes down who owns staging and posts it in the team channel by Friday."
4. Put the work in the sprint. The Scrum Guide says the most impactful improvements may even be added to the Sprint Backlog for the next Sprint. An action that isn't in the plan competes with sprint work and usually loses.
5. Turn outside problems into a conversation. When an action needs someone outside the team, the action is the ask: "Aisha raises the shared staging budget with the platform lead on Tuesday and reports back at the next retro."

Retro Rabbit is built around this loop. Assign To is required on every action. At the next retro, the Previous Retro tab shows what you agreed last time, and Old / Unresolved Items keeps older open actions in view. With CarrotIQ, on the Pro AI plan and in the trial, CarrotIQ Suggest drafts an action that weights the most-voted notes, for you to edit. For the full playbook, see retrospective action items that actually get done.

Where to start

For the wider picture, including formats, agendas and who should attend, see the sprint retrospective guide. If your retros have problems beyond these four, how bad retrospectives can sink a team has a 10-question checklist to score yours.

Try it in Retro Rabbit

Open a board at the start of your next sprint and let the team add notes as things happen, then start the retro with last sprint's actions already on screen. The 14-day free trial needs no card and includes CarrotIQ. See pricing for the per-team plans.

Related

• Sprint retrospective guide
• Retrospective action items that actually get done
• How to run an async retrospective
• 60 sprint retrospective questions
• Why we built Retro Rabbit
• Start Stop Continue retrospective