Most teams that stop taking retrospectives seriously don't do it because the meeting is badly run. They do it because nothing changes afterwards. The same three complaints come up every two weeks, someone writes "improve communication" on a sticky note, and by the fourth sprint people are quietly checking email. This post is about the part of the retrospective that decides whether it's worth the hour: what you commit to, how you make it small enough to finish, and how you check it next time.
Why retrospectives go stale
Look at the action items from your last five retrospectives. If you can't find them, that's the first problem. If you can, the usual pattern is some mix of these:
- Too many actions. Six items, none finished, all quietly dropped.
- No owner. "We should look into flaky tests" belongs to everyone, which means no one.
- Too big. "Rewrite the deployment pipeline" won't fit next to sprint work, so it never starts.
- Outside the team's control. "Product should give us requirements earlier" is a complaint, not an action.
- Never revisited. The next retrospective starts with a blank board, so nobody notices that nothing happened.
Every one of these is a problem with how the meeting ends and how the next one begins, not with the activity in the middle. You can use the same "went well / didn't go well" columns forever and still get results if you fix the ends.
A structure that leaves time to decide
Esther Derby and Diana Larsen's Agile Retrospectives: Making Good Teams Great describes five stages: set the stage, gather data, generate insights, decide what to do, and close the retrospective. The PTMP study guide uses the same shape. The stage that gets squeezed in practice is "decide what to do", because discussion overruns and the team ends up picking actions in the last three minutes.
For a one-hour retrospective on a two-week sprint, protect the time explicitly:
| Minutes | Stage | What happens |
|---|---|---|
| 0–10 | Set the stage, review last actions | Restate the purpose; go through last sprint's actions: done, not done, or dropped |
| 10–25 | Gather data | Everyone adds what happened, silently first, then grouped |
| 25–40 | Generate insights | Vote on one or two themes; ask why they happened |
| 40–55 | Decide what to do | Agree one action (two at most), with owner and check date |
| 55–60 | Close | Read the actions back; quick rating of the retro itself |
Two details matter here. First, the review of last time's actions comes before new data. If you leave it to the end, it gets skipped. Second, the timebox on insights is a hard stop. When the clock hits 40 minutes, you move to deciding, even if the discussion is good. A great conversation that ends in no action is the most common way retrospectives die.
Setting the stage doesn't need a speech. Norm Kerth's Project Retrospectives (2001) introduced what he called the Prime Directive: the assumption that everyone did the best job they could, given what they knew at the time, their skills, the resources available and the situation. Whether or not you read it aloud, that assumption is what lets people describe what went wrong without it turning into blame.
Pick one action, not five
The single most useful rule: leave each retrospective with one improvement action, two if the second is genuinely small. A team that finishes one improvement every sprint makes 20-odd changes a year. A team that writes down five and finishes none makes zero, and learns that retrospectives are theater.
When the team has voted on a theme, generate options and then narrow them down with three questions:
- Can we do it inside the team? If it needs another team or a manager's decision, the action is to ask, with a named person and a date, not to wait.
- Can it be done or tried within the next sprint? If not, cut it down to the first step that can.
- Will we be able to tell whether it worked? Name what you'd see if it did.
Everything that doesn't make the cut goes on a visible "parked" list. People let go of an idea much more easily when they can see it's been written down rather than lost.
Write actions that can be finished
Most bad actions can be fixed by rewriting them. Take the vague version and make it concrete:
| Vague | Finishable |
|---|---|
| Improve communication with QA | Sam invites QA to refinement for the next two sprints; we check at the next retro whether fewer stories bounced back |
| Fix flaky tests | Aisha quarantines the five most frequent flaky tests by Wednesday and opens a ticket for each |
| Better estimates | For the next sprint, any story estimated above 5 points gets split before planning; Lee checks the board on day one |
| Product should give requirements earlier | Jordan raises with the product manager by Friday: can we see the top 10 backlog items a week before planning? |
| Fewer interruptions | Trial: one person per day handles incoming requests; everyone else holds focus time until 1 p.m. Review in one sprint |
(The names are hypothetical; use your own team's.)
Every row on the right has the same four parts:
- An owner. One person, who volunteered. They don't have to do all the work, but they make sure it happens.
- A concrete first step. Something that can be started on Monday.
- A date or duration. Usually "by the next retrospective".
- A check. What you'll look at to decide whether it helped.
Many improvements work better framed as experiments: "for one sprint, we'll try X and look at Y". Experiments are easier to agree to because they're reversible, and they give you a natural point to keep, adjust or drop the change.
Make the action part of the sprint
An action that lives only in the retrospective notes competes with sprint work and loses. Put it where the rest of the work lives:
- Add it to the sprint backlog as an item, with the owner assigned. The Scrum Guide itself suggests that the most impactful improvements may be added to the Sprint Backlog for the next Sprint.
- Account for it in capacity at sprint planning. If the action takes half a day, that half-day comes out of feature work, and you make that trade openly.
- Mention it at the daily stand-up when it's in progress, like any other item.
This is where you, as the manager, have the most leverage. If you treat improvement work as something people do in their spare time, the team will conclude it doesn't matter. If you protect time for it in planning, they'll take it seriously.
Start the next retro with last time's actions
Keep a simple running log across retrospectives, in the same place every time:
Retro log
| Date | Action | Owner | Status | Result |
|------------|------------------------------------------|--------|---------|---------------------------------|
| 2026-10-06 | QA joins refinement for 2 sprints | Sam | Done | 2 bounced stories, down from 6 |
| 2026-10-20 | Quarantine top 5 flaky tests by Wed | Aisha | Open | |
| (parked) | Look at test environment provisioning | | Parked | |
At the start of each retrospective, go through the open rows. Each one gets one of three outcomes:
- Done: did it help? Keep the change, adjust it, or undo it.
- Not done: why not? If it was crowded out, decide whether it's still the most important thing. If it is, carry it over and protect the time. If not, drop it explicitly.
- Dropped: say so and write it down. Dropping an action on purpose is fine. Letting it disappear is what erodes trust.
The log also shows you patterns that a single meeting can't. If the same theme comes back three retrospectives in a row and the team's actions haven't moved it, it's probably not something the team can fix alone. That's your cue to take it on yourself: escalate it, raise it with the other team's manager, or put it in your own priorities. Recurring themes outside the team's control are some of the most useful signals a retrospective gives a manager.
Your role in the room
New managers often either run the retrospective too tightly or stay out of it entirely. Neither works well.
- Talk last. If you share your view of what went wrong first, you've set the agenda. Let the team's data go up before yours.
- Own your part. If a problem traces back to a decision you made, such as accepting a late scope change, say so plainly. It makes it safer for others to do the same.
- Don't take every action. If you own most of the actions, the team learns that improvement is your job. Take the ones only you can do, usually the ones involving other teams or upward requests.
- Rotate the facilitator. Once the team has the habit, let others run it. Fresh formats come with fresh facilitators, and you get to participate instead of chairing.
- Watch for silence. Silent writing before discussion helps quieter people contribute. If someone never adds anything, ask about it privately in your one-on-ones, not in the room.
Before your next retrospective
Do these three things, in this order:
- Find the actions from your last three retrospectives and put them into a log like the one above. Mark each one done, open or dropped.
- Open the next retrospective with that log, before anyone adds new notes.
- Stop the discussion at 40 minutes and leave with one action that has an owner, a first step, a date and a check.
Then ask yourself one question at the following retrospective: did the action from last time actually happen? If the answer is yes three sprints running, your team will start treating the retrospective as the place where things get fixed, and the quality of what people bring to it will rise with that.