Decide What to Do in a Retrospective: Prioritize Actions

Decide what to do in a retrospective: prioritize improvements with voting and a control check, then commit to one or two owned actions for the next sprint.

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

Deciding what to do is the fourth phase of the Five-Step Retrospective Framework. Its job is to turn the insights the team has just agreed on into a small number of concrete improvements. Retromat's summary of the decide-what-to-do phase is "Pick a few issues to work on and create concrete action plans of how you'll address them" (Retromat). The phase is where a retrospective becomes useful to the next sprint.

The main decision is how much to take on. Teams tend to leave with too many actions, because every insight seems to deserve one and nobody wants to dismiss a colleague's idea. The Agile Alliance's description of retrospectives warns against both too few and too many actions and says "one or two improvement ideas per iteration retrospective may well be enough" (Agile Alliance). MindTools' summary of the five steps gives the same advice: prioritize the insights and select one or two for action planning (MindTools).

The second decision is what kind of action to take. The best actions are within the team's control and small enough to finish in the next sprint. Ben Linders describes steering teams toward "actions that they could do in the next increment" and away from things the organization would need to do (Ben Linders). Some issues are outside the team's control, and the useful action there is to influence someone or to change how the team responds.

The third decision is how the action will be carried out. An action needs a clear description, an owner, a way to tell when it is done, and a place in the team's plan. The Scrum Guide notes that the most impactful improvements "may even be added to the Sprint Backlog for the next Sprint" (Scrum Guide), which puts improvement work alongside product work instead of on a separate list that gets forgotten.

This skill covers how to prioritize retrospective improvements, which voting techniques to use, how to check that an action is realistic, and how to write it so it gets done.

How It Works

The phase runs in four moves: generate options, narrow, shape and commit.

Generating options starts from the insights and the side list of solutions parked earlier. For each insight the team proposes one or more possible changes. Retrium lists Start Stop Continue, Impact/Effort/Energy mapping and Hypotheses and Experiments among decide-phase activities (Retrium). Framing a change as an experiment helps when the team is unsure it will work, because it sets an expectation of learning.

Narrowing uses a quick, fair method. Dot voting is a common retrospective voting technique. Nielsen Norman Group recommends giving each person a number of votes equal to "roughly a quarter of the total number of options", voting quietly with no lobbying, and having junior people vote before senior ones to protect the votes of those less likely to speak up (Nielsen Norman Group). The same article names the pitfalls: persuaded voting, split votes and group think. An impact and effort grid works well as a second pass on the top few options.

Shaping checks that each candidate is realistic. Diana Larsen's Circles and Soup sorts issues into what the team controls, what it can influence, and "the soup" it can only respond to, with direct, influencing or response actions for each. An action in the team's control can start tomorrow. An action that depends on another team becomes a request with a named person to make it.

Committing makes the action concrete. Ben Linders advises teams to "state what should be done, be specific", to keep actions small, and to "ask for volunteers for actions, don't assign them" (Ben Linders). Each action ends the phase with a volunteer owner, a definition of done and a place in the team's plan. Atlassian's retrospective play also calls for assigning owners and deadlines (Atlassian).

The ideas that lose the vote still have value. Record them on an improvement backlog with the insight they came from, so a later retrospective can pick one up when capacity allows. Saying out loud which ideas are being set aside, and where they are kept, makes it easier for people to accept a short list without feeling dismissed.

Step-by-Step Guide

Step 1: List candidate improvements

Start from the agreed insights and the side list of solutions. For each insight, ask what change would address its cause. Write each candidate as a short action phrase. Merge candidates that are really the same change. Keep ideas that came from successes, since repeating what worked is also an improvement.

Step 2: Dot vote to find the team's priorities

Give each person a small number of votes, roughly a quarter of the number of candidates. Ask people to vote silently, and reveal or count votes only when everyone has finished. Read the result aloud and discuss only the top few. If votes split evenly, ask the people who voted for each option to make the case in a sentence, then vote again on the finalists.

Step 3: Check control and effort

For each top candidate, ask whether the team can do it on its own, can influence it, or can only respond. Estimate roughly how much effort it would take in the next sprint. Drop or reshape candidates that depend entirely on others or that would take more capacity than the team has. Turn out-of-control issues into a specific request or a change in how the team responds.

Step 4: Choose one or two actions

Select the one or two actions the team will actually carry out. Say out loud which good ideas are not being taken now, and record them on an improvement backlog so they are not lost. If the team insists on more, ask which of the chosen actions it would drop to make room. A short list the team finishes builds more trust than a long list it abandons.

Step 5: Write each action so anyone can tell when it is done

Describe what will change, who will do it, and when progress will be checked. Add a definition of done and the signal that would show the change is working. If the change is uncertain, write it as an experiment with a review date. Read the result back and ask whether anyone would interpret it differently.

Step 6: Get a volunteer owner and a place in the plan

Ask who will own each action and wait for a volunteer. Put the action into the sprint backlog or on the team board where the team plans its work. Agree when the team will look at progress, at the latest in the next retrospective. Hand the list to the close, which will read it back to the whole team.

Best Practices

• Limit the list to what the team will do. The Agile Alliance suggests one or two improvement ideas per retrospective may well be enough.
• Vote silently and simultaneously. Nielsen Norman Group recommends no lobbying during voting and letting junior participants vote first.
• Prefer actions within the team's control. They can start immediately and do not stall waiting on another group.
• Ask for volunteers rather than assigning owners, as Ben Linders recommends, so the owner is committed to the outcome.
• Write actions as experiments when the outcome is uncertain. An experiment with a review date makes it acceptable to learn that a change did not work.
• Put actions where the team plans its work. An action on a separate list competes with nothing and is easy to forget.

Common Mistakes

• Leaving with a long wish list: Many actions spread attention thin, and most do not get done. Choose one or two and keep the rest on an improvement backlog.
• Writing vague actions: "Improve communication" cannot be finished or checked. Say what will change, who will do it and how the team will know it happened.
• Choosing actions the team cannot carry out: Actions that depend on other teams or management stall. Turn them into a specific request with a named person, or pick something the team controls.
• Assigning owners to absent or reluctant people: An owner who did not volunteer rarely drives the action. Ask for volunteers and keep the action small enough that someone will.
• Letting the loudest voice decide: Open discussion favors confident speakers. Use silent voting before discussion so the choice reflects the whole team.

References

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

Related Skills

• Generating Insights from Retrospective Data
• Closing a Retrospective Meeting Effectively
• Tracking Retrospective Action Items Across Sprints

Sources

• Retromat: What is a retrospective
• Agile Alliance Glossary: Heartbeat Retrospective
• MindTools: Sprint Retrospectives in Agile Project Management
• Ben Linders: How I Started with Agile Retrospectives
• The Scrum Guide
• Retrium: The Five Phases of a Successful Retrospective
• Nielsen Norman Group: Dot Voting
• Diana Larsen: Circles and Soup
• Ben Linders: Practical and Personal Retrospective Actions
• Atlassian Team Playbook: Sprint Retrospective

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