Retrospective action items: why they never get done

The retro is over. The team had a good discussion, a list of action items was written down, everyone leaves satisfied. Two weeks later, at the next retro, someone asks what became of those action items. Silence. Nobody really knows, and the same topics reappear on the cards.

It is the most common flaw of retrospectives, and the most costly: a retro whose action items don’t get done is just a discussion, and the team ends up realizing it. The causes are almost always the same, and nearly all of them can be fixed during the session.

The six reasons they don’t get done

1. There are too many

Eight action items for a two-week sprint, on top of the planned work, is a wish list. Nobody explicitly chooses to drop them: they simply come after everything else.

2. They are too vague

“Communicate better”, “Pay more attention to tests”, “Improve the specs”. These are intentions, not action items: you can neither start them nor say when they are finished.

3. They belong to “the team”

An action item given to everyone is given to no one. Everyone assumes someone else is on it.

4. They have no due date

Without a date, an action item is never late, so never urgent. It slides from one sprint to the next until it is forgotten.

5. They disappear between retros

Written in meeting notes nobody reopens, or on a board archived at the end of the session, action items leave the team’s field of view at the very moment they should enter it.

6. They don’t depend on the team

“Have more time”, “Get the business to prioritize better”: an action item the team can’t carry out itself is bound to stay open. The actionable version is almost always a step to take: go and see someone, propose something, measure a problem to make it objective.

Writing an action item that gets done

A good retro action item fits in one sentence and answers three questions: what (a concrete step, which you will be able to call done), who (one person, not a group) and when (a date, ideally before the next retro). A few rewriting examples:

And one limit: one to three action items per retro, no more. If the team identifies more, it chooses. That is precisely what the vote is for: discussing, and therefore acting on, only what matters most.

Keeping them in sight

A well-written action item can still be forgotten if it is filed in the wrong place. Three habits change everything:

• Set them during the session, not after. The owner and the date are decided while everyone is there. An action item “to be assigned later” won’t be.
• Make them visible between retros. In the Sprint Backlog, on the team’s board, or in the retro tool itself: a place the team already looks at, not a document you have to go and find.
• Open the next retro with their status. A few minutes at the start of the session: done, not done, dropped (and why). That is what gives the team proof that the retro changes something.

Action items and decisions are not the same thing

Not every conclusion of a retro is a task. “We no longer deploy on Friday afternoons” has no owner and no due date: it is a decision, a rule the team sets itself. Writing it down as an action item means seeing it “done” and forgotten. Keep two lists: action items, which get closed, and decisions, which stay valid until the team revisits them.

In SquadRetro

In SquadRetro, every action item leaves the session with an owner and a due date, set during the retro. Action items and decisions can be checked and ticked off at any phase, without leaving the session, and all of the squad’s are gathered on its page, session after session. For the rest of the flow, read the guide to running an agile retrospective.