Sorting Team Feedback into the 4Ls Categories
A skill from the 4Ls Sprint Retrospective: Liked, Learned, Lacked, Longed For method.
Sort team feedback into the 4Ls categories, tell Liked, Learned, Lacked and Longed For apart, and resolve notes that fit more than one.
Sort team feedback into the 4Ls categories, tell Liked, Learned, Lacked and Longed For apart, and resolve notes that fit more than one.
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
| Field | Value |
|---|---|
| Difficulty | Intermediate |
| Time to Learn | One or two retrospectives |
| Outcome | You can help a team place each note in the right 4Ls category, merge duplicates and resolve ambiguous notes quickly, so the board reflects what people meant. |
| Prerequisites | Familiarity with the 4Ls categories, experience in at least one retrospective |
| Part of | 4Ls Sprint Retrospective |
Overview
Sorting feedback into the 4Ls categories sounds trivial until a team does it. A note like "code review got faster once we paired" could be Liked or Learned. "No staging data" and "a seeded staging database" are the same gap written as Lacked and as Longed For. When notes land in the wrong place, clusters split, votes scatter and the team ends up discussing a theme twice under two names. This skill covers how to define the categories so people sort well on their own, and how to resolve what is left.
The categories come from Mary Gorman and Ellen Gottesdiener's original EBG write-up, which gives each L a plain meaning: what people liked, what they learned, what they lacked and what they longed for. Guides that followed add detail. Parabol's template describes Liked as things enjoyed or appreciated about the process or project, Learned as knowledge gained by individuals or the team, Lacked as missing elements that could have improved the process, and Longed For as future-focused wishes. The method page covers why each category exists.
Perfect sorting is not the goal. The categories are prompts that help people think of different kinds of feedback, and a note in the "wrong" column still carries its meaning. Sorting matters to the extent it affects clustering, voting and the actions that come out. A facilitator who spends ten minutes debating whether one note is Lacked or Longed For has lost sight of that.
How It Works
Most sorting problems come from three pairs of categories that overlap.
| Pair | How to tell them apart |
|---|---|
| Liked and Learned | Liked is a practice or outcome to repeat. Learned is new knowledge the team did not have before. |
| Lacked and Longed For | Lacked describes the past sprint: what was missing. Longed For describes the future: what the team wants. |
| Learned and Lacked | "We learned we need more test coverage" is a Lacked item phrased as a lesson. Ask whether the note is new knowledge or a missing thing. |
A simple test resolves most notes: ask what the team would do with it. A note that leads to "keep doing this" is Liked. A note that leads to "write this down or teach it" is Learned. A note that leads to "fix this gap" is Lacked. A note that leads to "propose or request this" is Longed For. The action-type test works because the categories were designed to produce different kinds of follow-up.
Some notes genuinely belong in two places. Lacked and Longed For pairs are the most common, and that duplication is useful: the Lacked note is evidence, the Longed For note is a proposal. Group them together during clustering, even across columns, so the team discusses the gap once. Ben Linders' description of the exercise has the team review notes for clarity and cluster similar items before voting, which is where these cross-column links are made.
Who does the sorting also matters. Writers should place their own notes during silent writing, because they know what they meant. The facilitator only proposes moves during clustering, and the writer has the final say. In EBG's version, four subgroups each take one poster, read its notes and identify themes, which spreads the sorting work across the team and gives each group ownership of one category.
Step-by-Step Guide
Step 1: Define Each Category Before Writing Starts
Before silent writing, spend a minute explaining the four Ls with one concrete example each from this team's world. Put a short definition and a prompt at the top of each column, so people can check while they write. Spend the most time on Lacked versus Longed For, since that pair causes the most confusion. Tell people that a note in the wrong column is fine and can be moved later. This lowers the pressure and speeds up writing.
Step 2: Let Writers Place Their Own Notes
During silent writing, each person decides where each of their notes goes. Ask for one idea per note, since a note with two ideas often belongs in two columns. Provide a small "not sure" area for notes the writer cannot place. Do not correct placement during writing; interrupting breaks concentration and signals that sorting is a test. The writer's first instinct is usually close enough.
Step 3: Read Each Column and Flag Misfits
When writing ends, walk through the columns one at a time. Read each note and ask the room whether it fits. If a note looks misplaced, ask the writer what they meant rather than moving it yourself. Apply the action-type test when there is doubt: keep, teach, fix or propose. Move the note only if the writer agrees.
Step 4: Resolve the Not-Sure Area
Take each note from the not-sure area and ask its writer what they want the team to do about it. Place it by that answer. If it genuinely fits two categories, place it in the one that leads to the more useful action and add a small link to the other. If it fits none, it may be a question or a topic for another meeting, so park it. Clear this area before clustering starts.
Step 5: Merge Duplicates and Link Pairs
Group notes that say the same thing, keeping every original note visible in the group so the count of people who raised it is clear. Name each group with a short phrase that states the issue. Link Lacked and Longed For notes that describe the same gap, even across columns, so they are voted on and discussed as one theme. Avoid merging notes that only look similar; "slow reviews" and "unclear review criteria" may have different causes. When unsure, keep them separate and let the vote decide.
Step 6: Check the Board with the Team
Before voting, give the team a minute to scan the final board. Ask whether any note is misrepresented by its group name or position. Adjust names that do not match what people meant. This check takes little time and prevents a vote on a theme nobody actually raised. Then move on to prioritizing.
Best Practices
- Use examples from the team's own recent work when explaining the categories. Generic examples are easy to agree with and hard to apply.
- Treat categories as prompts, not a filing system. If a note is clear and the team understands it, its column matters less than its content.
- Always ask the writer before moving a note. Moving someone's note without asking can feel like being corrected in public and makes people more cautious next time.
- Keep duplicate notes visible inside their group. The number of people who raised something is information the vote should see.
- Link Lacked and Longed For pairs rather than deleting one. The pair gives the team both the evidence and a proposal, which makes the action easier to write.
- Write theme names as statements of the issue. "Release checklist unclear" is easier to act on than "Releases".
Common Mistakes
- Debating placement at length: Long arguments about whether a note is Lacked or Longed For waste time that belongs to discussion. Apply the action-type test, let the writer decide and move on.
- Facilitator re-sorting the board alone: Moving notes without asking changes their meaning and erodes trust. Propose moves and let the writer confirm.
- Over-merging: Collapsing different issues into one group hides distinct causes and produces vague actions. Merge only notes that describe the same thing.
- Ignoring Liked and Learned during clustering: Teams cluster Lacked carefully and skim the rest. Cluster every column, since Liked themes tell the team what to protect.
- Notes with more than one idea: A note that says "standups were good but the release was chaotic" cannot be placed or voted on cleanly. Ask for one idea per note and split any that combine two.
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
- Writing 4Ls Retrospective Questions for Each Category
- Turning 4Ls Retrospective Insights into Action Items
- Running a 4Ls Retrospective for Remote and Hybrid Teams
Sources
- EBG Consulting: The 4L's, a retrospective technique
- Parabol: 4Ls retrospective template
- Ben Linders: Four L's, a classic retrospective exercise
Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.
Other Skills in This Method
Running a 4Ls Retrospective for Remote and Hybrid Teams
Run a 4Ls retrospective for remote and hybrid teams with async input, a short video session, hidden voting and equal footing for everyone.
Building a 4Ls Retrospective Board and Template
Build a reusable 4Ls retrospective board and template, physical or digital, with prompts, voting space and an action area the team reuses.
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.
Writing 4Ls Retrospective Questions for Each Category
Write 4Ls retrospective questions for Liked, Learned, Lacked and Longed For that draw specific, usable feedback out of every team member.
Facilitating a 4Ls Sprint Retrospective Meeting
Plan, timebox and facilitate a 4Ls sprint retrospective meeting so every person contributes and the team leaves with owned action items.
Tracking 4Ls Retrospective Trends Across Sprints
Track 4Ls retrospective trends across sprints: log and tag themes and actions so recurring, systemic problems become visible and get fixed.
Related Methods and Skills
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.
Generating Insights from Retrospective Data
Generate insights in a retrospective: cluster the sprint data, find patterns and use the 5 Whys or a fishbone to reach causes the team can act on.
Running Sprint Retrospectives for Continuous Improvement
Retrospective facilitation for agile teams: set the stage, gather data, find causes, and leave with a few owned changes the team follows up.
Closing a Retrospective Meeting Effectively
How to end a retrospective: read back the action items and owners, thank people, collect a quick ROTI on the session and close on time.
Facilitating Sprint Retrospectives for Scrum Teams
Facilitate a scrum retrospective that inspects how the Sprint went and ends with one or two owned improvements the team actually carries out.
Facilitating a Start Stop Continue Retrospective
How to run a start stop continue retrospective: prepare, review the facts, write in silence, group and vote, then leave with a few owned actions.
Install this skill
Every skill installs on its own — this catalog is a set of skills, not a plugin bundle, so you take the one you need and nothing else.
Claude Code
.claude/skills/categorizing-feedback-into-4lsnpx skills add gethamster/skills --skill categorizing-feedback-into-4ls --agent claude-code --yesCursor
.agents/skills/categorizing-feedback-into-4lsnpx skills add gethamster/skills --skill categorizing-feedback-into-4ls --agent cursor --yesCodex
.agents/skills/categorizing-feedback-into-4lsnpx skills add gethamster/skills --skill categorizing-feedback-into-4ls --agent codex --yesAntigravity
.agents/skills/categorizing-feedback-into-4lsnpx skills add gethamster/skills --skill categorizing-feedback-into-4ls --agent antigravity --yesOr browse the skills and pick interactively:
npx skills add gethamster/skillsSource: gethamster/skills on GitHub, MIT licensed.