Turning 4Ls Retrospective Insights into Action Items

Turn 4Ls retrospective insights into a few concrete action items with one owner and a due date each, carried into 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

Turning 4Ls retrospective insights into action items is the step that decides whether the meeting was worth holding. A board full of well-named themes changes nothing on its own. What changes the next sprint is a small number of specific commitments that someone owns, that fit in the sprint, and that someone checks. This skill covers the decide-what-to-do phase: picking which themes to act on, writing actions that can be finished, assigning them and closing the loop.

The Scrum Guide sets the expectation plainly: the team identifies the most helpful changes, addresses the most impactful ones as soon as possible, and may add them to the next Sprint Backlog. In Derby and Larsen's five phases, deciding what to do is the fourth phase, after gathering data and generating insights. The 4Ls feed it in a particular way, because each category tends to produce a different kind of action.

The common failure is breadth. Teams leave with a long list of vague intentions like "improve communication", nobody owns any of them, and the same themes return next sprint. The fix is to do less, more precisely. The method page covers the categories themselves; this skill starts once the board has been clustered and voted on.

How It Works

Each of the four Ls points toward a different type of action.

Knowing the type helps the team write the action. A Liked theme such as "pairing on risky changes" becomes "add pairing to the definition of done for changes to the payments module". A Longed For theme such as "production-like test data" becomes a spike or a request to the platform team, not a promise to build a data pipeline this sprint.

Choosing which themes to act on comes from the vote. The Nielsen Norman Group's dot-voting guidance is to vote silently and let less senior people vote first, which keeps the ranking honest. Take the top one or two themes, not all of them. The rest stay on the record and are reviewed next time.

A useful action has four properties. It is concrete enough that anyone could tell whether it was done. It has one named owner, because "the team" means nobody. It has a due date, usually before the next retrospective. And it lives where the team tracks its other work, so it competes for time openly rather than being forgotten. GitLab's handbook asks that every retrospective action be assigned to group members with clear expectations for when it will be completed, which covers the owner and the date.

Some themes cannot be fixed by the team: a missing hire, a shared environment, a policy. The action for those is an escalation with an owner and a date for raising it. Recording them as team actions guarantees failure and teaches the team that retrospectives cannot fix real problems.

Finally, the loop closes at the next retrospective. Opening with a quick review of each action, done or not and why, is what makes the commitments real.

Step-by-Step Guide

Step 1: Mark the Shift from Discussion to Decisions

Announce clearly that the team is moving from discussing themes to deciding on actions, and state how much time is left. Protect this phase with its own timebox, because discussion always expands to fill the meeting. Restate the top themes from the vote so everyone is working from the same list. If the discussion has already run long, cut the number of themes to act on rather than cutting this phase. A short, finished decision phase beats a long discussion with no decisions.

Step 2: Pick the Themes to Act On

Take the top one or two themes by vote. Check each against a simple question: can the team change this in the next sprint, or does it need someone outside? Keep Liked and Learned themes in consideration, since protecting a practice or sharing knowledge is a legitimate action. Link any Lacked and Longed For notes that describe the same gap, so the team writes one action for both. Leave the remaining themes on the board and say they will be reviewed next time.

Step 3: Write Each Action as a Concrete Step

For each theme, ask what the smallest change would be that would make a difference. Write it as a verb and an object: "write a release checklist for the mobile app", not "improve releases". Check that anyone could tell at the next retrospective whether it was done. If the action is too big for one sprint, write the first step as the action. Avoid actions that depend on everyone behaving differently, such as "communicate better", because nobody can own them.

Step 4: Assign One Owner

Ask for a volunteer for each action, and make sure the owner is a single person. The owner does not have to do all the work, but they are the one who makes sure it happens. Avoid defaulting to the Scrum Master or the lead; spreading ownership spreads commitment. Ask the owner to restate the action in their own words, which surfaces misunderstandings immediately. If nobody will take an action, that is a signal it is not important enough, so drop it.

Step 5: Set a Due Date and Put It in the Backlog

Give each action a date, usually before the next retrospective. Add it to the sprint backlog or tracker during the meeting, which the Scrum Guide explicitly allows for the most impactful improvements. Size it like other work so it has real capacity in the sprint. If it will not fit, make it smaller rather than adding it without capacity. Link the action back to the theme and the retrospective it came from.

Step 6: Escalate What the Team Cannot Fix

For themes outside the team's control, write an escalation action: who will raise it, with whom, and by when. Include the evidence from the board, since the Lacked notes are the case for the request. Track the escalation like any other action. When the answer comes back, report it at the next retrospective. Teams that see escalations answered keep raising real problems.

Step 7: Review Actions at the Next Retrospective

Open the next retrospective by going through each action: done, partly done or not done. For anything not done, ask briefly what got in the way, without blame. Carry an action forward at most once; if it slips twice, either shrink it or drop it deliberately. Note whether completed actions actually changed anything, which feeds the next round of Liked or Lacked notes. Keep a record of actions and their outcomes across sprints, so recurring themes are visible.

Best Practices

• Act on fewer themes than seems ambitious. A short list that gets done builds trust in the retrospective; a long list that does not undermines it.
• Include a Liked or Learned action when one is on the top of the vote. Keeping a good practice alive is often cheaper and more valuable than fixing a new problem.
• Write actions the way you write backlog items, with a verb, an object and a clear finish. If it cannot be tracked like other work, it probably will not be done.
• Put actions in the same backlog as feature work. A separate retrospective list is easy to ignore; the sprint backlog competes for time openly.
• Let owners volunteer rather than assigning them. Volunteered ownership comes with more commitment, and a theme nobody volunteers for is useful information.
• Check completed actions for effect as well as completion. An action that was done but changed nothing is a reason to revisit the cause.

Common Mistakes

• "The team" as owner: Shared ownership means no one follows up. Put one person's name on every action, even if several people do the work.
• Vague actions: "Improve communication" or "be more careful with releases" cannot be checked. Rewrite until the next retrospective could say yes or no.
• Too many actions: Leaving with a long list spreads effort thin and most items slip. Act on the top one or two themes and park the rest.
• Team actions for problems the team cannot fix: Promising to solve a staffing or infrastructure issue sets the team up to fail. Write an escalation with an owner instead.
• Never reviewing actions: If nobody checks, the team learns commitments are optional. Make the review the first agenda item of every retrospective.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: 4Ls Sprint Retrospective

Related Skills

• Building a 4Ls Retrospective Board and Template
• Facilitating a 4Ls Sprint Retrospective Meeting
• Tracking 4Ls Retrospective Trends Across Sprints
• Sorting Team Feedback into the 4Ls Categories
• Writing 4Ls Retrospective Questions for Each Category
• Running a 4Ls Retrospective for Remote and Hybrid Teams

Sources

• The Scrum Guide
• Derby, Larsen and Horowitz: Agile Retrospectives, Second Edition
• Nielsen Norman Group: Dot voting
• GitLab Handbook: Group retrospectives

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