Retrospective action items
that actually get done

Most retrospective action items die on the whiteboard. Learn how to write, own, and follow through on action items that drive real team improvement.

7 min read

Why action items fail

Retrospectives generate insights, but insights alone do not change anything. The gap between a good observation and a real improvement is the action item — and most teams get it wrong.

Too vague.Items like “improve communication” sound productive but give nobody a clear next step. Without specificity, the item is a wish, not a task.

No owner.When an action item belongs to “the team,” it belongs to nobody. Without a single person accountable for follow-through, items slip through the cracks.

Too many at once. Teams that leave a retro with eight action items complete zero of them. Overcommitting dilutes focus and guarantees nothing gets done.

Not tracked.If action items live only in the facilitator's notes, they are invisible to the rest of the team. What is not visible is not prioritized.

Never reviewed. The worst habit is moving on without looking back. When the team never checks whether previous items were completed, it signals that retro outcomes do not matter.

Writing effective action items

Good action items share four qualities. They are specific, owned, time-bound, and small enough to finish before the next retrospective.

Specific

Define exactly what needs to change. Instead of 'improve testing,' say 'add integration tests for the checkout flow.' Precision removes ambiguity and makes completion obvious.

Owned

Assign a single person responsible for driving the item forward. Shared ownership means no ownership. The owner does not have to do all the work — they just make sure it happens.

Time-bound

Set a clear deadline, ideally before the next retrospective. Without a timeframe, action items drift into the 'someday' pile and never get done.

Small

Keep items completable within one sprint. If an action item feels too big, break it down. Small wins build momentum and prove that retrospectives lead to real change.

The action item lifecycle

From identifying an issue to celebrating its resolution, every action item follows four steps.

1

Identify during the retro

Vote on the top issues the team raised. Focus on the items with the highest impact and the most energy behind them. Trying to fix everything at once fixes nothing.

2

Define clearly

Rewrite each selected item as a concrete, actionable task. A good action item reads like a ticket — anyone on the team should understand what 'done' looks like.

3

Assign an owner

Ask for volunteers rather than assigning. People follow through on commitments they choose. If nobody volunteers, the item may not be important enough to pursue.

4

Review next retro

Open every retrospective by reviewing the previous action items. Celebrate completions, discuss blockers, and decide whether incomplete items should carry forward or be dropped.

Making follow-through a habit

The best action items still fail without a system for follow-through. These four practices make completion the default.

Start each retro with a review

Dedicate the first five minutes to checking the status of previous action items. This creates accountability and shows the team that retro outcomes matter.

Add items to the sprint backlog

For items that require development effort, create tickets and prioritize them alongside feature work. Invisible work stays undone.

Make progress visible

Track action items where the team already looks every day — the project board, a Slack channel, or the retro tool itself. Visibility drives completion.

Celebrate completed items

Acknowledge wins publicly. When the team sees that action items lead to real improvements, they invest more energy in future retrospectives.

Good vs bad action items

The difference between an action item that gets done and one that gets ignored often comes down to how it is written.

Vague

Improve communication

Actionable

Add a 5-minute standup recap in Slack by Friday

Vague

Write more tests

Actionable

Add unit tests for auth module this sprint — owned by Sarah

Vague

Reduce tech debt

Actionable

Refactor the payment service error handling before next retro — owned by James

Vague

Be more careful with deployments

Actionable

Add a pre-deploy checklist to the CI pipeline by end of week — owned by Lin

Frequently asked questions

Aim for 1 to 3 action items per retrospective. Fewer items with follow-through are far more valuable than a long list that gets ignored. Pick the highest-impact items the team can realistically complete before the next retro.

Every action item needs a single owner — not 'the team.' The owner is responsible for driving the item to completion, though they may delegate tasks. Volunteering is better than assigning; people follow through on commitments they choose.

Recurring carry-overs signal that items are too large, not prioritized, or lack ownership. Break them into smaller steps, allocate sprint capacity for them, or escalate blockers. If an item has carried over 3 times, reassess whether it is truly a priority.

Yes, for items that require development effort. Treating action items as sprint work ensures they compete fairly for capacity rather than being invisible side tasks. For process changes, a simple checklist may suffice.

Use whatever tool your team already checks daily — your project board, a shared document, or the retrospective tool itself. The key is visibility. Review the status of previous action items at the start of each retrospective.

Capture your next action items

Run a retrospective with your team, vote on the top issues, and walk away with clear action items — completely free.