The Action Item Graveyard: Why Retro Improvements Die

Every team has a place where retro action items go to disappear.

Sometimes it is an old Miro board. Sometimes it is a Google Doc. Sometimes it is a tab in a spreadsheet with a hopeful name like "Improvements".

The first few rows look sensible. Better release notes. Clearer code review habits. Earlier risk flags. Then sprint work takes over, the team forgets to look, and the same actions return in the next retro under slightly different names.

This is the action item graveyard.

It is not usually caused by laziness. It happens because the team has made improvement work too easy to ignore.

Action items die when nobody owns them

"The team will improve documentation" sounds collaborative. It is also a neat way to make sure nobody does it.

Shared ownership is useful for values. It is poor for tasks.

Every retro action item needs one named owner. That person does not need to do all the work alone. They do need to move it forward, ask for help, and bring back an update.

A better version:

• Weak: Improve onboarding docs.
• Better: Priya will add the deployment checklist to the onboarding doc by Friday.

Now the team knows who to ask and what done looks like.

They die when there is no date

An action item without a date has no pressure behind it.

A date does not make every item urgent. It tells the team when it expects to learn from the action.

A due date also helps with scope. If the item cannot be done within the sprint or soon after it, it is probably too large. Break it down.

For example:

• Too large: Fix flaky tests.
• Better: Identify the five noisiest flaky tests and agree what to do with each by next Wednesday.

The second version may not solve the full test problem. It does create movement.

They die when the wording is vague

Many retro actions are too soft to survive contact with a busy sprint.

"Improve communication" can mean anything. More Slack updates. Fewer Slack updates. Better tickets. More meetings. Fewer meetings.

Write retro actions like small tickets:

• Start with a verb.
• Name the thing that will exist or change.
• Add a clear finish line.

Examples:

• Add a blockers section to the daily stand-up notes.
• Create a pull request checklist for changes touching payments.
• Move release notes drafting to Wednesday before release day.
• Ask design to attach acceptance criteria before engineering picks up a ticket.

Each one can be checked without a long debate.

They die when there are too many

A long list of actions can make a retro feel productive. It often means the team has avoided a hard choice.

Most sprint teams can only carry one or two improvement actions at a time. That is not a lack of ambition. It is respect for the real workload.

If the board has ten good ideas, vote on them. Choose the smallest action that would remove the most friction next sprint. Keep the rest as notes, not commitments.

A small action that happens is worth more than a perfect list that nobody touches.

They die when they sit outside the team's work

Retro actions are often treated as a special kind of work. They are not.

If the team uses Jira or Linear, put improvement actions there. If the team plans from a backlog, review them in planning. If the team checks a board every morning, make the actions visible on that board.

This is one reason SprintPulse syncs retro action items both ways with Jira and Linear. It helps the team turn feedback into owned, dated work without asking people to remember another document. SprintPulse can also summarise themes with AI and suggest action items, which saves the facilitator from turning a messy board into a clean list by hand.

They die when nobody reviews them

The first five minutes of the next retro should answer three questions:

• Did we finish the action?
• If yes, did it help?
• If no, what got in the way?

Keep the tone calm. The aim is to learn how the team handles its own commitments.

Sometimes an action was too broad. Sometimes the owner had no space. Sometimes the problem changed. Sometimes the team simply forgot. Each answer tells you something useful.

Without that review, the team learns that retro promises do not matter.

A better action item format

Use this template:

[Owner] will [specific action] by [date], so we can [expected result]. We will know it is done when [check].

Example:

Lena will add deployment status updates to the release Slack thread by Thursday, so support can see when a release is delayed. We will know it is done when the next release thread includes the update format.

That is a real commitment. It is small, visible, and testable.

Keep the graveyard small

You will never finish every possible improvement. That is fine. The goal is not to empty the retro board. The goal is to make sure the work you do choose has a fair chance.

Give each item an owner, a date, a clear finish line, and a place in the team's normal work. Review it next time.

The useful part is not the board itself. It is the habit the board supports: feedback, decision, owner, date, follow-up.