On this page (9 sections)
This post first appeared on our old blog in 2021 (by Ben Staples). We've rewritten and updated it for 2026.
Bad retrospectives sink a team slowly. Nobody notices one dull retro. But when wins go unrecognized, problems get discussed without being understood, and the same issues come back every sprint, people stop believing the meeting matters. Then they stop saying anything useful in it. The fix is rarely a new format. It's working out which failure mode you're in, and who can fix it.
This post covers the three ways bad retros hurt a team, the anti-patterns that cause them before, during and after the meeting (including newer ones from async and remote work), how to write action items that are actually SMART, and a 10-question checklist to score your own retro.
Three ways bad retros sink a team
A lot of advice covers the cost of not holding retros at all. These are the problems teams have when they do hold them.
Morale
The team can't celebrate wins
Retros drift toward problems, because "What didn't go well?" always has the most notes. A retro with no recognition is a short road to what Ben called "no-morale city": people start to dread the meeting, and over time it can push good people out. Read the wins first, all of them, big and small.
Inspection
The team can't inspect what happened
Inspection is the core of a retro, and it's often missing. Teams stay on surface complaints ("standup ran long"), review individual meetings, or relitigate one stakeholder conversation. Real inspection looks for themes across several sprints and asks why they keep happening.
Change
The team doesn't fix anything
A retro is a feedback loop: you run the sprint, look back, and change something. If no actions come out, or they come out and disappear, the loop never closes. The Agile Alliance warns that when the same issues recur at each retro without measurable improvement, the retro may have become an empty ritual.
Each has several causes, and they show up at different points in the cycle. In the tables below, "who can fix it" means the facilitator (often the Scrum Master), the team, or the manager and wider organization.
Where retros go wrong
-
Before the retro
Nobody gets ready
No preparation, no focus, no shared data, an empty async board, or the retro gets cancelled.
-
During the retro
The wrong conversation
One voice dominates, complaints jump straight to actions, or the time goes on things the team can't control.
-
After the retro
Nothing changes
Too many actions, actions lost in a tracker, and no review at the start of the next retro.
Anti-patterns before the retro
| Anti-pattern | What you see | Who can fix it | Fix |
|---|---|---|---|
| No preparation | The facilitator opens a blank board as the meeting starts | Facilitator | Spend 15 minutes the day before: check last retro's actions, pick a format, gather sprint facts |
| No focus | Every retro asks "how did it go?" and gets the same answers | Facilitator | Give the retro a focus when something notable happened, such as a missed sprint goal or a big release |
| No shared data | Everyone argues from their own memory of the sprint | Facilitator and team | Notes added during the sprint, plus facts: sprint goal met or not, incidents, releases |
| An async board nobody adds to | The board opened on day one and has two notes on day nine | Facilitator and team | Seed one example note, ask for one note a week, remind at standup, read the async notes aloud in the meeting |
| The retro is the first thing cancelled | It disappears whenever a deadline gets close | Manager | Treat it as fixed; shrink it to 15 minutes instead of cancelling |
The first three come from Esther Derby's Eight Reasons Retrospectives Fail (2010), still the best short list on the subject. Her point about data matters most for teams that work async: notes written on the day something happened are the shared data.
The empty async board is newer. Opening the board early only helps if people use it, and they won't if their notes vanish into a meeting that never mentions them. More on this in how to run an async retrospective.
Anti-patterns during the retro
| Anti-pattern | What you see | Who can fix it | Fix |
|---|---|---|---|
| Loudmouth | One or two people do most of the talking | Facilitator | Silent writing first, timed turns, pairs or small groups, names optional on notes |
| Wheel of Fortune | The team jumps from complaints straight to actions | Facilitator | Ask why before deciding: 5 Whys or a fishbone on the top-voted group |
| In the Soup | Most of the time goes on things the team can't control | Team | Sort issues into what you control, what you can influence, and what's in the soup |
| Problems only | The wins column never gets read | Facilitator | Read every win first, and timebox each column |
| Surface inspection | The same small complaints, sprint after sprint | Team | Look across the last three to five retros for themes that repeat |
| The manager effect | People go quiet when the manager joins | Manager | Speak last, skip some retros, take the actions that need your authority |
| Remote retro fatigue | Cameras off, one-word notes, people multitasking | Facilitator | Shorter calls, writing moved out of the call, rotating formats and facilitators |
Wheel of Fortune, In the Soup and Loudmouth are three of Aino Vonge Corry's retrospective antipatterns, published on Martin Fowler's site. They overlap with two of Derby's reasons: one or two people dominating, and focusing only on impediments outside the team's control.
The In the Soup sort is most useful for what comes next. Items the team controls get normal actions. Items it can only influence get a different kind of action, usually a conversation with the person who can change them. Items in the soup get acknowledged and set aside. That middle group matters: a 2026 survey of 419 people by Easy Agile, a tool vendor, found that 28.9% of retro actions need changes outside the team's control (State of Team Alignment 2026).
The manager effect comes from the Agile Alliance, which notes that a manager's presence can inhibit discussion. Remote fatigue isn't new either: distributed teams were already a top challenge for 36% of respondents in Retrium's 2017 survey, also vendor data. The biggest drain on a remote retro is ten minutes of silent typing on a video call. Move that into the sprint, and the call shrinks to the part that needs people together: discussing and deciding. To break the routine, try a different format every few sprints, such as Sailboat or Mad Sad Glad, or a short opener from our retrospective icebreakers.
Anti-patterns after the retro
| Anti-pattern | What you see | Who can fix it | Fix |
|---|---|---|---|
| Too many actions | Seven actions agreed, none finished | Team | One or two per sprint, three at most |
| No energy for the action | It's important, but nobody wants to do it | Team | Rate candidates on importance and on the team's energy for them; pick ones that score on both |
| A separate improvement plan | Actions live in a document nobody opens | Team and manager | Put improvement work in the sprint backlog with all the other work |
| Actions lost in a tracker | Actions become tickets and never come up again | Facilitator | Review them at the start of the next retro, wherever they live |
| AI summaries nobody reads | A summary gets generated and filed | Facilitator | Read it aloud at the start of the next retro, or send it to stakeholders with the actions |
| No review of last actions | Every retro starts from scratch | Facilitator | Open every retro with last retro's actions: done, in progress, or drop it |
The first three are Derby's last three reasons. Her energy point is the one teams skip most: an action the team doesn't care about loses to sprint work every time, however important it looked in the meeting.
Her eighth reason, the separate improvement plan, has a modern form: actions that become tickets and are never seen again. Putting the work in your tracker is right. Never looking at it again in the retro is the problem. If an action lives in a ticket, put the ticket number in the action text so the review takes seconds.
The AI summary problem is new. A summary makes it easy to feel the retro is "documented" without anyone reading the result. Treat it as input, not output: it earns its keep when someone reads it, checks it against the votes, and uses it to start the next conversation.
Targeting the next retro doesn't make an action SMART
The 2021 version of this post said that if you run Scrum and set the next retrospective as the deadline, your actions automatically hit every SMART criterion. That isn't right, and it's worth explaining why.
SMART stands for Specific, Measurable, Attainable, Relevant and Time-bound. A deadline of "by the next retro" gives you one of those: the T. It also gives you a natural checkpoint, which is valuable. But it doesn't make an action specific, measurable, attainable or relevant. Take "Improve code reviews by next retro":
| Letter | Question to ask | "Improve code reviews by next retro" | Better |
|---|---|---|---|
| Specific | What exactly changes, and who does it? | No | Marcus and Jun agree that every PR gets a first review within 24 hours |
| Measurable | How will we know it worked? | No | At the next retro, we count the PRs that waited longer than a day |
| Attainable | Can it be done this sprint, alongside sprint work? | Unknown | It's a small item on the sprint backlog, not extra work on top |
| Relevant | Does it address what the team voted on? | Maybe | It targets the top-voted group, "PRs waiting for review" |
| Time-bound | When do we do it, and when do we check? | Yes | Marcus posts the rule in the team channel by Wednesday; we check at the next retro |
The same action, put together
Time-bound only
- "Improve code reviews by next retro"
SMART
- Marcus and Jun agree that every PR gets a first review within 24 hours.
- Marcus posts the rule in the team channel by Wednesday.
- At the next retro, we count how many PRs waited longer.
Two more corrections to the original. First, "by the next retro" isn't automatically attainable. If the work isn't in the sprint plan, it competes with sprint work and usually loses. Adding it to the sprint backlog is the step that makes it happen, as the Scrum Guide suggests:
The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
Second, some changes are too big for one sprint. For those, the action is the first step that fits: "Elena drafts a proposal for splitting the deploy pipeline and shares it by Thursday", not "fix the pipeline". More examples are in retrospective action items that actually get done.
Score your retro: a 10-question self-check
Answer these about your last retro, one point for each yes.
- Did the retro start with a review of the last retro's action items?
- Were most of those actions done, or dropped on purpose?
- Did notes arrive during the sprint, not only on retro day?
- Did everyone on the team add at least one note?
- Were the wins read out, not just the problems?
- Did the team discuss why the top issue happened before deciding what to do about it?
- Was most of the discussion about things the team can control or influence?
- Did the retro end with no more than three actions, each with one owner and a date?
- Is each action in the sprint plan, or somewhere the team will see it before the next retro?
- Can someone name one thing that changed because of a retro in the last two months?
| Score | What it means | What to do |
|---|---|---|
| 8–10 | Healthy: the loop works | Keep it fresh. Rotate formats and facilitators, and score it again next quarter |
| 5–7 | Working in the room, leaking somewhere | Fix your weakest phase first. If you lost points on questions 1, 2, 8 or 9, that's follow-through, and it's the best place to start |
| 0–4 | At risk of becoming an empty ritual | Reset. For the next two sprints, agree on one action only, put it in the sprint, and open the next retro with it. Then hold a short retro about the retro itself |
Who can fix what
If you facilitate
You own the preparation, the agenda and the timer
Plus the first five minutes of every retro. Most of the during-the-meeting anti-patterns are yours to fix.
If you're on the team
You own the notes and the actions you take on
Say so out loud when the retro isn't working. Add one note a week, and take on one action at a time.
If you manage the team
You own the conditions
Protect the retro from cancellation, make room in the sprint for improvement work, take the actions that need your authority, and know when to stay out of the room. Derby also points out that a retro can't fix a blame culture or relentless deadlines. Those are yours too.
For the basics behind all of this, see the sprint retrospective guide. For the problems teams name most often, read the biggest problem agile teams have with retrospectives.
Try it in Retro Rabbit
Retro Rabbit is built for the "after" part. Every action item needs an owner, and the Previous Retro and Old / Unresolved Items tabs bring open actions back at the next retro, so reviewing them is the obvious first step. Start a 14-day free trial with no card needed, and open the board on day one of your next sprint. See pricing.
Related
Frequently asked questions
What makes a retrospective bad?
A bad retrospective produces no change. The same issues return, wins go unmentioned, one or two voices dominate, or actions are agreed and then forgotten. The Agile Alliance warns that issues recurring at every retro without measurable improvement may mean the retro has become an empty ritual.
What are retrospective anti-patterns?
They are habits that seem reasonable but make retros worse, such as jumping from complaints straight to actions, spending the meeting on problems the team can't control, or letting one person dominate. Esther Derby and Aino Vonge Corry have both written widely cited lists.
How do you fix a retrospective that feels pointless?
Start with follow-through. Open the next retro by reviewing the last one's actions, agree on only one or two new ones, give each an owner and a date, and put the work in the sprint backlog. When people see something change, they start taking the retro seriously again.
What is a SMART action item in a retrospective?
One that is Specific, Measurable, Attainable, Relevant and Time-bound. 'Improve code reviews' is not SMART. 'Marcus posts a 24-hour first-review rule in the team channel by Wednesday, and at the next retro we count how many PRs waited longer' is. Setting the next retro as the deadline only covers the time-bound part.
Should managers attend sprint retrospectives?
It depends on trust. The Agile Alliance notes that a manager's presence can inhibit discussion. If a manager joins, they should speak last, take the actions that need their authority, and accept that some retros work better without them.
How do you get people to contribute to an async retro board?
Open the board on day one, add an example note yourself, and ask for one note a week rather than a full list. Remind people at standup, and read the async notes out at the start of the meeting so everyone sees they get used.
Run retros that actually lead to change
Your team adds notes during the sprint, CarrotIQ groups and summarizes them and suggests action items, and unfinished items carry into the next retro.
14-day free trial · No credit card