Tracking Retrospective Action Items Across Sprints

Tracking retrospective action items: keep improvements visible, give them capacity, review them every retro and watch whether problems stop recurring.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A retrospective only improves a team if its actions get done. Tracking retrospective action items is the work between retrospectives that makes that happen: keeping each action visible, giving it time in the sprint, checking it at the next retrospective, and noticing whether the problem it addressed has gone away. The Five-Step Retrospective Framework ends each meeting with owned actions. This skill is about what happens to them next.

Follow-through is where many teams fail. Esther Derby, co-author of Agile Retrospectives, describes teams that "fall into a rut, or fail to act on their retrospective resolves" (Esther Derby). Ben Linders reports that teams sometimes stop doing retrospectives because their actions "weren't done and kept coming back in the retrospective" (Ben Linders). The Agile Alliance's description of the practice gives the symptom: identical issues coming up at each retrospective without measurable improvement "may signal that the retrospective has become an empty ritual" (Agile Alliance).

The fixes are simple, and teams skip them anyway. Put actions where the team plans its work so they compete for time with everything else. Review them at the start of every retrospective, as a routine. Keep them few enough to finish. Decide what to do with actions that stall, rather than letting them linger.

Retrospective accountability comes from the team's routine more than from pressure on individuals. An owner who volunteered for an action, sees it on the board every day and knows it will be reviewed in front of the team has what they need to finish it. An owner whose action lives in meeting notes nobody reads does not.

This skill covers where to record actions, how to make room for them in the sprint, how to run the review at each retrospective, how to keep an improvement backlog, and how to tell whether the team is actually improving.

How It Works

Tracking has four parts: visibility, capacity, review and trend.

Visibility means the action is in front of the team during the sprint. Ben Linders recommends that actions are "added to the status board and/or to the backlog, so that they are visible and will not be forgotten" (Ben Linders). The Scrum Guide says the most impactful improvements "may even be added to the Sprint Backlog for the next Sprint" (Scrum Guide). Atlassian recommends entering actions in the team's project tool and linking the related tickets, so they are part of sprint planning and easy to review (Atlassian).

Capacity means the sprint has room for the action. An improvement that has to fit around a full sprint of product work usually loses. Plan it in sprint planning like any other item, sized small enough to finish. Linders advises keeping actions small, with a clear definition of when they are done (Ben Linders).

Review means checking every open action at the start of the next retrospective. Linders writes that he usually starts a retrospective by looking at the previous actions to see if they are finished (Ben Linders), and Retrium lists reviewing the action plan as a set-the-stage activity (Retrium). For each action the team asks: is it done, did it help, and what now? Unfinished actions are carried forward deliberately, reshaped, or dropped with a reason.

Trend means looking across several sprints for sprint retrospective improvement tracking. A simple log of actions, their outcomes and the problems they addressed shows whether issues stop recurring. When the same theme keeps returning despite actions, that is a signal for deeper analysis; Linders suggests a root cause analysis when teams are unable to improve (Ben Linders).

Ideas that were good but not chosen go on an improvement backlog. The team can pull from it in later retrospectives, and it shows people their suggestions were not lost.

Keep the review short and factual. It is a check on the team's own commitments and should never become a status report to a manager. If most actions are unfinished sprint after sprint, the cause is usually too many actions, actions that are too large, or no capacity planned for them, and the next decide phase should respond to that.

Step-by-Step Guide

Step 1: Record each action precisely before the retrospective ends

Write each action with what will change, the owner, the definition of done and when it will be reviewed. Note the insight behind it in one line. Confirm the wording with the owner and the team. Vague actions cannot be tracked, so fix them now.

Step 2: Put actions on the board or in the backlog

Add each action to the team board or the sprint backlog where daily work is planned. A separate retrospective document is easy to forget. Use the same format as other work items so it is not treated as second class. Link any related tickets or notes. Make sure the owner's name is visible.

Step 3: Plan capacity for improvement work

In sprint planning, size each action and include it in the sprint's commitment. If the sprint is already full, decide explicitly what gives way. Keep actions small enough to finish within the sprint. An action that needs more than a sprint should be split into a first step.

Step 4: Mention actions during the sprint

Refer to improvement actions in daily check-ins alongside product work. Ask owners if anything is blocking them. Offer help early rather than discovering at the retrospective that an action stalled. Visibility during the sprint does most of the tracking work.

Step 5: Review every action at the next retrospective

Start the retrospective with the previous actions. For each, ask whether it is done and whether it helped. Decide explicitly for unfinished ones: carry forward, reshape or drop. Use the result as data for the rest of the retrospective.

Step 6: Keep an improvement backlog and a simple log

Store good ideas that were not chosen on an improvement backlog and look at it when choosing new actions. Keep a short log of actions, outcomes and the problems they addressed. Review the log every few sprints to see which themes keep returning. Use recurring themes as candidates for a deeper root cause analysis.

Best Practices

• Record actions where the team plans its work. Ben Linders recommends the status board or backlog so actions are visible and not forgotten.
• Review previous actions first in every retrospective. It keeps the review from being squeezed out and shows the team that actions matter.
• Keep actions few and small. The Agile Alliance suggests one or two improvement ideas per retrospective may well be enough.
• Drop actions deliberately. Removing a stalled action with a reason is better than carrying it forward indefinitely.
• Track outcomes as well as completion. An action that was done but did not help is a finding, and the next retrospective should know about it.
• Watch for recurring themes. Repeated issues without improvement mean the actions are not reaching the cause.

Common Mistakes

• Keeping actions in meeting notes: Notes are rarely read again. Put actions on the board or in the backlog where daily work happens.
• Not planning capacity: Improvement work squeezed around a full sprint rarely happens. Include it in sprint planning.
• Skipping the review: If the next retrospective does not check the actions, people learn that they do not matter. Make the review the first item.
• Carrying actions forward forever: A long list of stale actions erodes trust in the process. Reshape or drop actions that have stalled for more than one sprint.
• Counting completions without checking impact: Finishing an action is not the same as solving the problem. Ask whether the issue has stopped recurring.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Five-Step Retrospective Framework

Related Skills

• Decide What to Do in a Retrospective: Prioritize Actions
• Closing a Retrospective Meeting Effectively
• Gathering Data in Retrospectives

Sources

• Esther Derby: Agile Retrospectives, the Heart of Team Improvement
• Ben Linders: Getting Retrospective Actions Done
• Ben Linders: Practical and Personal Retrospective Actions
• Agile Alliance Glossary: Heartbeat Retrospective
• The Scrum Guide
• Atlassian Team Playbook: Sprint Retrospective
• Retrium: The Five Phases of a Successful Retrospective

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.