The Follow-Through Index: do retrospective action items actually get done?

Do retrospective action items actually get done? Mostly, yes. Across hundreds of thousands of action items tracked in TeamRetro, about 73% were eventually completed, not the “one in three” that gets quoted everywhere. About half are done within three months, and about a quarter before the team’s next retro. The factor that moves the number most is assignment: an action with a named owner and a due date completes about 90% of the time.

That figure comes from teams who run their retros in a dedicated tool, so read it as what good looks like rather than an industry average. The rest of this page shows the working.

Ask why retrospectives fail and someone will throw a statistic at you, some version of “only about a third of retro action items ever get done.” It’s everywhere. It’s sourced nowhere. Nobody actually knows the number.

We do. TeamRetro runs enough retrospectives to measure the one thing that decides whether the hour was worth it: do teams actually do what they decide? Our sample is hundreds of thousands of real action items, not a survey and not a guess.

It’s not a third. It’s nearly three-quarters.

The headline: about 73% of retro actions actually get done

Across a sample of hundreds of thousands of action items committed in real retrospectives, ~73% were eventually completed. Not one in three. Closer to three in four. The clock matters, so here it is up front: about half of actions are done within three months of being written, about a quarter before the team’s next retro, and the rest of the eventual completions arrive over a long tail.

Before you frame it and hang it on the wall: this is a ceiling, not a national average. These are teams who care enough to run retros in a dedicated tool, so read it as what good looks like, not what everyone does. But it kills the folklore stone dead. “About a third” isn’t the truth about retrospectives anywhere we can see: even the teams with no retro rhythm at all complete around 55%. The folklore gets the direction right and the size wrong, and the gap it gestures at, rhythm and ownership, is exactly what the rest of the data is about.

Why action items don’t get done

Most advice on this question is a list of assertions. Here are the failure modes we can actually see in the data, and one we cannot, flagged as such.

Nobody owns it. Only about 40% of actions get an owner at all. Owned-and-dated actions complete about 90% of the time; the unowned, undated ones sit far lower, at about 67%. This is the largest measurable gap on the page and it is free to close.

There is no date. Just ~11% of actions ever get a due date. A date is the cheapest commitment device available in a retro, and nine actions in ten leave the room without one.

It was too big for one cycle. The median action takes about six weeks to finish, and most teams retro more often than that. An action the size of a quarter looks abandoned by the next meeting even while it is moving, and a team that reads “not done” as “failed” stops committing to the big ones at all.

It was never the team’s to fix. Some actions are really a request aimed at someone else: headcount, a cross-team dependency, a deployment pipeline nobody in the room owns. Filed as a team action it sits there. Raised as an escalation with a name and a date against it, it moves. We have not measured this one. It is the pattern behind a lot of the never-done quarter, and we treat it at length in why retrospectives fail.

Nobody looked at it again. This is the big one, and the data is blunt about it. Teams that retrospect on a regular cadence complete about three in four of their actions; teams that retro only occasionally fall to around 55%. The mechanism is not mysterious: a cadence is the thing that forces the review, and without a review nothing gets closed. The fix is a habit, not software.

That last one is worth sitting with, because it is the cheapest and the most ignored. The roughly one in four actions that are never completed at all live overwhelmingly in the corner where these failures stack: no owner, no date, no rhythm.

Lever 1: cadence. Teams with a rhythm finish; teams without one don’t.

The biggest single split in the data is how regularly a team retrospects.

• Teams that retro on a regular cadence complete about three in four of their actions.
• Teams that retro only occasionally (long gaps between sessions, or a handful of retros ever) fall to around 55%.

Same tool, same features, opposite outcomes. And it isn’t only completion: occasional teams take about twice as long to close what they do finish (getting on for three months, versus roughly six weeks for teams with a rhythm). A retro isn’t a meeting; it’s a loop. Teams that keep the loop turning close the loop. Teams that don’t, don’t.

This is the uncomfortable one for the retros-are-theatre crowd: retros aren’t the problem. Irregular retros are.

Lever 2: ownership. An action without an owner is a wish.

Here’s the finding you can act on this afternoon. Actions given a named owner and a due date get completed about 90% of the time. Actions with neither sit around two in three.

And yet teams barely use it. Only about 40% of actions get an owner at all, and just ~11% ever get a due date. That’s the gap: not effort, not intent, assignment. Most teams leave the retro with a list of good intentions and no names on it, then wonder why the list is still there next fortnight.

So the advice writes itself, and it’s the opposite of what most facilitators optimize for. Don’t leave with the longest list of things you could do. Leave with two that each have a name and a date. An action without an owner isn’t an action; it’s a wish the whole team has quietly agreed to ignore.

The myth-buster: retrospectives outrun their own actions

Now the finding that should change how you judge follow-through. When teams walk into their next retro, most of the last retro’s actions aren’t done yet, and that panics people. It shouldn’t.

Actions take about six weeks (median) to complete, and most teams retro faster than that. So the real shape of follow-through is roughly:

• ~1 in 4 actions done by the next retro,
• ~1 in 2 done, but after the next retro has already come and gone,
• ~1 in 4 never done at all.

Half of all the actions teams write get finished late by the retro’s clock, not because they were abandoned but because they were still in flight when the calendar came around again. So “why isn’t last retro’s action done?” is usually the wrong question. The one to ask is whether it’s moving. Judge follow-through on a quarter’s rhythm, not a fortnight’s.

The last line of that list is the real void: about one in four actions are never completed, and they live overwhelmingly in the unowned, no-due-date, no-cadence corner of the data. Everything above is how you climb out of it.

How to make them stick

Seven steps, in order. None of them are software.

1. Leave with one or two actions, not ten. The longer the list, the worse each item on it does: retros that leave with ten or more actions complete about 56% of them, against about 79% for retros that leave with one to three. Pick the change that would matter most and let the rest go. If the team genuinely surfaced ten problems worth fixing, that is a list to prioritize, not a list to commit to.
2. Put a person’s name on each one. Not a team, not a role, not the Scrum Master by default. One person who said yes out loud. The owner is not the person who does all the work. They are the person accountable for it moving, and for saying where it got to next time.
3. Put a date on it before the meeting ends. Not “next sprint”, a date. This is the step teams skip: only about one action in nine ever gets one, and owned-and-dated actions are the ones completing at ~90%.
4. Size it to fit one cycle. If the action cannot plausibly be finished before the next retro, it is not an action yet. Split it into a first slice that can be, or reframe it as an experiment: a hypothesis, a review date, and an honest look at what happened. An experiment that taught the team something is a success even without a tick in a box, while an action item that quietly rolls over for six sprints teaches the opposite lesson.

5. Write it into the next block of work. An action that lives only on the retro board is competing with the sprint instead of being part of it. Put it wherever the team actually takes work from, so finishing it is the work rather than something extra alongside it. Our own timing data argues for this step hardest: the median action takes about six weeks to close while the median team retros every two. Johanna Rothman has recommended this shape for years in Create Your Successful Agile Project: one item, treated as an experiment, with the next block of work framed to include it.
6. Open the next retro with last time’s actions, before anything new. This is the habit that carries the rest. Read them out, say what is done, and for anything that is not, ask whether it is still moving rather than who is to blame. It is the highest-value five minutes in the meeting and the first thing teams drop. Lionel Luchez, a software engineering manager at Snapsheet, describes it in BuiltIn’s piece on making retrospectives more actionable as the whole first phase of their retro: “Phase one is reviewing closed gaps since the last meeting.” Nothing new goes on the board until that is done.
7. Track your completion rate, not your action count. Count how many of last quarter’s actions actually closed, and watch that number rather than how many stickies the team produced. It is the only retro metric worth reporting upward, and it is the one that improves when steps 1 to 6 become routine.

How to track them, and when you don’t need a tool

Start with the honest floor: a shared doc with three columns, action, owner and due, read out at the top of every retro will beat any tool nobody opens. If your follow-through is broken today, the missing piece is almost certainly the review habit rather than the software. Fix the habit with whatever you already have and you will get most of the gain in this data for nothing.

A tool earns its place by removing the three moments where that habit breaks:

• The action is captured with an owner and a date in the meeting itself, while the team is still in the room to agree to it, rather than written up afterwards by whoever took notes.
• Open actions from last time appear at the start of the next session, before anyone adds anything new. Nobody has to remember to go looking.
• Completion is recorded, so you can see your rate over a quarter instead of guessing at it.

That is what retrospective action tracking does in TeamRetro, and it is where the data on this page comes from.

Pushing actions into Jira, Linear or a backlog is fine, with one caveat we will be straight about. Once an action lives in your tracker, its completion is managed there, which is why we exclude those actions, about 2 to 3% of the sample, from this data: we cannot watch them finish, so we do not count them. Our own team works this way, as the sidebar above says, so our own published actions sit in that excluded slice too. That is a limit of our measurement, not evidence those actions fail. The practical risk is the same as the risk with a shared doc: an action that leaves the retro’s orbit only survives if something brings it back for review.

How we measured it

No survey, no self-report about self-report. These are events recorded in the product:

• Sample: a large sample of action items created in real retrospectives (type = action, explicitly accepted, not AI suggestions a facilitator dismissed) across teams using TeamRetro, with demo, internal and test accounts removed and accounts migrated between our hosting regions counted once. Hundreds of thousands of them, enough to be statistically robust across every segment we report.
• “Done” means an action was explicitly marked complete in-product, never inferred. We report completion “ever” and on fixed clocks (within three months, by the next retro) separately, because the gap between them is the whole story. The 73% headline is the “ever” number.
• What we left out, and why. Agreements are deliberately excluded: a team’s standing working agreements (“disagree and commit”, “cameras on for demos”) are ongoing norms, not tasks you tick off, and counting them would understate follow-through. So are the ~2–3% of actions published to an external tracker (Jira, mostly): once an action lives in Jira its completion is managed there, not in TeamRetro, so we only measure what we can actually watch finish. Both exclusions are conservative.
• We report medians and distributions, not just averages, because completion times are skewed and a mean would flatter us.
• One thing we went looking for and didn’t find: any correlation between a team’s follow-through and its own health-check scores. There’s essentially none: following through is a discipline, not a mood, and you can’t read one off the other.

What we wouldn’t claim

Five limits, stated plainly, because a number without them is not worth quoting.

• This is a ceiling, not an industry average. Teams who choose a dedicated retro tool almost certainly follow through more than teams who do not. Read ~73% as what good looks like, not as what everyone does.
• Some of “eventually” is housekeeping. A small share of completions arrive as bulk closes: ten or more actions marked done in the same minute, often six months or more after they were written. Some of that is real work being reconciled from an external tracker; some is a board being tidied, and we cannot always tell which. Discount every late bulk close and the headline floor is about 69%. Read us as “roughly seven in ten, given enough time” and you are inside the error bars either way.
• “Marked done” is not “made a difference.” Completion is the floor of impact, not proof of it. We can see that the action closed. We cannot see whether it worked.
• Some genuine agreements get mis-logged as actions and never complete, which drags the measured rate down. So for real tasks, if anything, the true number is a shade higher.
• We only measure what we can watch finish. Actions published to an external tracker are excluded, and so are standing working agreements. Both exclusions are deliberate and both are conservative.

And the claim we will not make about our own product: TeamRetro does not guarantee follow-through, and neither does anything else. It makes the habit easier to keep. That is a smaller claim, and it is a true one.

Privacy

Every figure here is aggregate and de-identified: event counts across many teams, never a single customer’s data, never anyone’s name, never the text of an action. Segments are only reported above a minimum team/action threshold. Full guardrails live in the internal spec.

Cite this

Across a sample of hundreds of thousands of retrospective action items tracked in TeamRetro, about 73% were eventually completed, roughly three in four, not the “one in three” of folklore: about half within three months, about a quarter before the team’s next retro. Completion rises to ~90% for actions given a named owner and a due date, and teams that retrospect on a regular cadence complete about three in four against around 55% for teams that retro only occasionally. — The Follow-Through Index, TeamRetro (2026)

Using this in research or a talk? We’d love a link back.

Where this leaves you

Follow-through is not a discipline problem and it is not a format problem. It is an assignment-and-review problem, and both halves are free: leave the retro with fewer actions, each carrying a name and a date, and start the next one by reading them out. If you would rather that happened without someone having to remember to make it happen, that is the job running your retrospectives in TeamRetro does. Every action carries its owner and its date forward into the next session, and the completion rate is there to look at.

Keep reading

• Why retrospectives fail (and how to make yours matter)
• The follow-through void (Agile Theatre)
• Are retrospectives worth it? A verdict
• How to run a retrospective
• A checklist for running your retrospective

Frequently asked questions

Do retrospective action items actually get done?

Mostly, yes, and considerably more often than the folklore says. Across hundreds of thousands of action items tracked in TeamRetro, about 73% were eventually completed, or roughly three in four. Eventually is the honest word: about half of actions are done within three months of being written, and about a quarter before the team’s next retro. The widely repeated claim that “only about a third get done” is quoted everywhere and sourced nowhere. The other caveat on our figure: the sample is teams who run their retrospectives in a dedicated tool, so treat 73% as what good looks like rather than a cross-industry average.

What percentage of retrospective action items get completed?

About 73% eventually, in TeamRetro’s first-party data, from a sample of hundreds of thousands of action items created in real retrospectives with demo and internal accounts removed. The rate splits sharply by practice: actions with a named owner and a due date complete about 90% of the time, teams that retrospect on a regular cadence complete about three in four, and teams that retro only occasionally fall to around 55%. About one in four actions are never completed at all.

Why don’t our retrospective action items ever get finished?

Usually one of five reasons, and only the first two are about effort: the action has no named owner (only about 40% of actions get one), it has no due date (only about 11% do), it was too big to finish inside one cycle, it was never the team’s to fix in the first place, or, most commonly, nobody looked at it again. The data is clear about which matters most: teams that retrospect on a regular cadence complete about three in four of their actions, while teams that retro only occasionally complete around 55%. The fix that moves the number is a review habit, not a new tool.

Why do actions from our last retro never seem done by the next one?

Because retrospectives outrun their own actions. The median action takes about six weeks to complete, and most teams retro more often than that, so roughly half of all actions are finished only after the next retro has already happened. “Not done yet” usually means “still moving”, not “failed”. Worry about the action that is not moving, not the one that is not finished by the next meeting.

How many action items should a retrospective produce?

One or two, each with an owner and a date, and each written into the next block of work rather than left on a board. Long lists do measurably worse: retros that leave with ten or more actions complete about 56% of them, against about 79% for retros that leave with one to three. An owner and a due date raise completion to about 90%, so two owned actions beat ten unowned ones every time. If the team genuinely surfaced ten problems worth fixing, that is a list to prioritize over the coming months, not a list to commit to this sprint.

Who should own a retrospective action item?

One named person who agreed to it in the meeting, not the team, not a role, and not the Scrum Master by default. The owner is not necessarily the person who does all the work; they are the person accountable for the action moving and for reporting on it at the next retro. Only about 40% of retrospective actions get an owner at all, and owned-and-dated actions complete about 90% of the time, which makes naming someone out loud before the meeting ends the cheapest improvement available to any team.

Should you review old action items at the start of a retrospective?

Yes, before anything new goes on the board. It is the highest-value five minutes in the meeting: it closes the loop on what the team already committed to, and it surfaces the actions that are not moving while there is still time to do something about them. Our data shows why it matters: teams with a regular retro rhythm complete about three in four of their actions while occasional-retro teams drop to around 55%, and the mechanism behind that gap is simply whether anything forces the review. When something is not done, the useful question is whether it is still moving, not who is to blame.

How do you track retrospective action items?

Capture each action with an owner and a due date in the meeting itself, keep the open ones somewhere the whole team can see, and read them out at the start of the next retro. A shared doc with three columns, action, owner and due, reviewed every session works, and beats any tool nobody opens. A dedicated retrospective tool helps by removing the three points where that habit breaks: it captures the owner and date while the team is still in the room, resurfaces open actions at the next session before anything new is added, and records completion so you can see your rate instead of guessing at it.

Should you push retrospective actions into Jira or Linear?

You can, and plenty of teams do, including ours: our own customer success team publishes each retro’s actions into Linear once every one has an owner. The thing that decides whether it works is not which tool holds the action but whether something brings it back for review, so keep reading the open list out at the start of the next retro even after it lives in your tracker. One note on the numbers on this page: actions published out to an external tracker are excluded from our dataset, about 2 to 3% of the sample, because their completion is recorded there and we only count what we can watch finish.

Are there tools that help retrospective action items get done?

Yes, a dedicated retrospective tool closes the loop a task list leaves open. TeamRetro, where this data comes from, lets you assign each action an owner and a due date in the meeting itself, keeps open actions visible at the next retro so they are reviewed before anything new is added, and records completion so you can see your rate improve. Whichever tool you use, those are the mechanisms that move the number: ownership, visibility next retro, and a measured completion rate. And if the review habit is not there yet, a shared doc read out at every retro will beat a tool nobody opens.

What do you do about actions the team cannot control?

Escalate them by name instead of listing them again. Sort every issue by who actually owns it, what the team controls, what it can influence, and what it can only live with, then turn the outer-ring items into a visible request that names the blocker, quantifies the cost, and names the person who needs to act and by when. An action the team was never able to complete is not a follow-through failure; it is an item filed in the wrong place. Keep one team-controlled improvement for the team to work on, and send the rest upward on the record.

How do you make retrospective actions actually happen?

Two things, in order. Retro on a regular cadence, because teams with a rhythm finish far more than teams who retro only occasionally. And give every action a named owner and a due date, because owned-and-dated actions complete about 90% of the time, yet only around a tenth of actions get a due date at all. Leaving with two owned actions beats leaving with ten unowned ones.