Retrospective Action Items That Actually Get Done: Write Them, Cap Them, Carry Them Forward

Retrospective action items get done when each one has a single owner, a verb, a clear "done when" and a date someone will check it; when the team picks only one to three per retro; and when the next retro starts by reviewing them. Most teams manage some of the first part. Very few do the last part, and that's where follow-through dies.

Below: why follow-through fails (and why the data disagrees), how to write an action item, what to do with problems your team can't fix alone, and a five-minute carry-forward routine. For the rest of the meeting, see the sprint retrospective guide.

Why retro action items don't get done

Four datasets get quoted about retrospective follow-through. All four come from retro-tool vendors, and their headline numbers range from about 13% to about 73%.

Follow-through in one vendor's product data

~73%

of retro actions are eventually completed

~25%

are done before the next retro

~6 weeks

median time to complete an action

Source: TeamRetro Follow-Through Index 2026

Why the numbers disagree

They aren't measuring the same thing.

• Different definitions of done. Easy Agile asks about actions implemented before the next retro. TeamRetro counts actions completed at any point, and its median time to complete is about six weeks. Kollabe counts items someone marked done in the tool. Retrium didn't measure completion at all: it asked people what their retros were good for.
• Product data vs. surveys. A survey records what people believe happened. Product data records what someone clicked. Kollabe found 68.7% of items still pending, and some of those were surely finished and never ticked off.
• Bulk closes. TeamRetro saw ten or more actions marked done in the same minute, often six months or more after they were written. Some is real work reconciled from another tracker; some is tidying the board. Excluding bulk closes drops its figure to about 69%. TeamRetro also leaves out actions pushed to an external tracker such as Jira, because it can't see what happens to them there.

Line up the time windows and the gap shrinks. TeamRetro's "about 25% done before the next retro" and Easy Agile's 69% describe the same problem: most actions are still open when the next retro starts.

The pattern they share

Every dataset that breaks completion down points the same way: an owner, a date and fewer items.

Owner and due date90%

Neither an owner nor a due date67%

Retros with 1–3 actions79%

Retros with 10 or more actions56%

Source: TeamRetro Follow-Through Index 2026 (approximate figures)

• TeamRetro: actions with both an owner and a due date complete at about 90%, vs. about 67% with neither. Retros with 1–3 actions complete about 79% of them; retros with 10 or more, about 56%.
• Kollabe: 23.2% of items with an owner reach done, vs. 8.6% without one. The 1.1% of items with a due date complete at 37%.
• Easy Agile adds one more lever, visibility. In its own product data, teams completed 40–50% of retro actions, rising to 65% after it added features that surface incomplete actions. Its 2026 survey also found 20.5% of actions never make it into sprint planning.

Yet TeamRetro found only about 40% of actions get an owner and about 11% get a due date. The levers aren't secret. Teams skip them.

How to write a retrospective action item

Use four parts: owner + verb + done-when + check date.

👤

Owner

One name

"The team" means nobody.

⚡

Verb

Something to start tomorrow

Write, ask, timebox, pair, remove, try.

✅

Done when

What will be true when it's finished

So nobody argues about it at the next retro.

📅

Check date

When you'll look at it

Usually the next retro, sometimes a standup sooner.

Write the date into the action text itself: "Jun drafts the PR checklist and posts it in the team channel. Check: Nov 12." The date then travels with the item wherever it goes: a ticket, a chat message, an export. Use the real date, not "Thursday". Two weeks later, nobody remembers which Thursday.

Formats that ask about behavior make this easier. Start Stop Continue notes are half-written actions already. In a Sailboat retro, anchors become removal actions and rocks become risk actions with a check date.

Action item examples: vague vs. done-able

Ten sprint retrospective action items, across the themes that come up most:

In the last one, the problem isn't the team's, but the action is. For prompts that produce sharper notes in the first place, see sprint retrospective questions.

Cap it at one to three per retro

Esther Derby, co-author of Agile Retrospectives, lists biting off more than the team can chew as one of eight reasons retrospectives fail. Her fix: "Choose one or two actions." The Agile Alliance glossary calls both too few and too many a mistake, and warns that when the same issues come up at every retro without measurable improvement, the retro may have "become an empty ritual."

TeamRetro's numbers back the cap (79% vs. 56%, above). A team that takes on eight improvements on top of a full sprint finishes none.

1. 1

   Vote first

   Discuss the top-voted groups, not everything on the board.

2. 2

   Rate importance and energy

   This is Derby's tip: a fix the team has no energy for won't happen, however important it is.

3. 3

   Save a slot for a leftover

   If last retro's item is half done and still matters. Re-scoping an old item often beats adding a new one.

Everything else stays on the board. If it matters, it'll come back.

Actions your team can't control

Easy Agile's 2026 survey found that 28.9% of retro actions need changes outside the team's control. In Retrium's 2017 survey, the top challenge (48%) was discussing topics the team couldn't solve on its own. Aino Vonge Corry calls this antipattern "In the Soup": the retro spends its time on things nobody in the room can change.

The fix is to change the action. The team can't own "the release process is too slow", but it can own the escalation.

Who to ask. The person who owns the constraint and can say yes: the platform lead, the PM, the engineering manager, another team's lead. If you're the Scrum Master, removing impediments is part of your job, so the owner is often you.

How to write it up. Keep the escalation short enough to read on a phone:

1. 1

   What's happening

   "Staging deploys need a ticket to the platform team and take two to three days."

2. 2

   Evidence

   "Four stories waited on staging last sprint. It was the top-voted group in our retro."

3. 3

   Cost

   "About five days of blocked work per sprint."

4. 4

   The ask

   "Can we get self-serve staging deploys, or a 24-hour turnaround?"

5. 5

   When you need an answer

   "By the 20th, so we can plan around it."

How to track it. Make the escalation itself the team's action item: "Priya sends the staging escalation to the platform lead; done when we have a yes, a no or a date. Check: Nov 20." Pair it with a workaround the team controls, such as batching staging requests on Mondays. If the answer is no, report it at the next retro, drop the item, and stop spending retro time on it until something changes.

The carry-forward playbook

This is the retrospective follow-up most guides leave out: what happens to action items between retros and at the start of the next one.

Every sprint

1 Agree 1–3 actions

2 Owner and check date

3 Plan them into the sprint

4 5-minute review next retro

5 Done, re-scope or drop

1. 1Agree 1–3 actions
2. 2Owner and check date
3. 3Plan them into the sprint
4. 45-minute review next retro
5. 5Done, re-scope or drop
6. ↺ Every sprint

1. Open every retro with a five-minute review

Before anyone writes a new note, go through last retro's actions. Each owner gives one word and one sentence.

Five minutes covers three items. If it takes longer, you have too many, which is itself a finding. If nothing got done, make that the retro's first topic.

Do it every time. TeamRetro found teams on a regular retro cadence complete about three in four actions, against about 55% for teams that retro occasionally.

2. The two-retro rule: re-scope or drop

An item with no progress across two retros gets one of two outcomes:

• Re-scope it: rewrite it as something smaller that fits in this sprint, with a new date. "Migrate CI to the new runners" becomes "Jun moves the lint job to the new runners. Check: Nov 26."
• Drop it: say so out loud ("We're dropping the docs overhaul. Nobody has had time, and it isn't hurting us yet.") and note the reason in your team channel.

Saying it out loud matters. A silently abandoned item teaches the team that action items are optional; an openly dropped one shows the list is real. If a dropped topic keeps coming back as top-voted notes, that's the Agile Alliance's empty-ritual signal: escalate it, or make it the only action next sprint.

3. Put improvement work in the sprint backlog

The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Scrum Guide says it plainly. Derby makes the same point from the other side: improvement work kept in a separate plan doesn't get done, so "put it in the real plan."

In practice: at sprint planning, each action's owner creates a ticket, sized like any other work and counted against capacity. An action that never reaches planning lands in Easy Agile's 20.5%.

4. How leftovers flow into the next retro

The rule is simple: open items carry forward; they don't get rewritten as new notes.

Instead, keep the original item, update its text and date, and let it come up in the next review. Anything still open after two retros meets the two-retro rule.

How Retro Rabbit handles follow-through

We built Retro Rabbit around this loop. The routine works in any tool; here's how it maps.

• Every action needs an owner. "Assign To" is required when you create an action item.
• Carry-over tabs. The Action Items panel on the board has three tabs: Current Retro, Previous Retro and Old / Unresolved Items. The five-minute review is the Previous Retro tab. The two-retro rule is the Old / Unresolved Items tab.
• Between retros, each person sees their open items under My Action Items on the dashboard.
• CarrotIQ Suggest. On the Pro AI plan and during the free trial, the "Create Action Item" dialog can draft an action from the retro's notes, weighting the most-voted ones and avoiding duplicates of existing items. Treat it as a first draft and add the done-when and check date yourself.

If your team has connected Slack, the assignee also gets a DM, and there's a "Remind" button to nudge them later.

Measuring follow-through

Three numbers tell you whether your retros lead to change. Track them in a simple sheet, one row per retro.

Recurring themes are common: the Kollabe dataset found the same complaints coming back across consecutive retros from the same team. Named groups make repeats easier to spot.

For more on measuring whether retros work, see the biggest problem agile teams have with retrospectives.

Try it in Retro Rabbit

Start a 14-day free trial, no card needed, with CarrotIQ included. Agree on one to three action items in your first retro, and each owner sees theirs under My Action Items until the next one. Plans are priced per team, not per user: see pricing.

Related

• The sprint retrospective guide
• How to run an async retrospective
• Sprint retrospective questions
• How bad retrospectives can sink a team
• Start Stop Continue template
• Sailboat template
• What Went Well template