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

FieldValue
DifficultyIntermediate
Time to LearnOne or two retrospectives
OutcomeYou 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.
PrerequisitesFamiliarity with the 4Ls categories, experience in at least one retrospective
Part of4Ls 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.

PairHow to tell them apart
Liked and LearnedLiked is a practice or outcome to repeat. Learned is new knowledge the team did not have before.
Lacked and Longed ForLacked 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.

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

Sources


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

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-4ls
npx skills add gethamster/skills --skill categorizing-feedback-into-4ls --agent claude-code --yes

Cursor

.agents/skills/categorizing-feedback-into-4ls
npx skills add gethamster/skills --skill categorizing-feedback-into-4ls --agent cursor --yes

Codex

.agents/skills/categorizing-feedback-into-4ls
npx skills add gethamster/skills --skill categorizing-feedback-into-4ls --agent codex --yes

Antigravity

.agents/skills/categorizing-feedback-into-4ls
npx skills add gethamster/skills --skill categorizing-feedback-into-4ls --agent antigravity --yes

Or browse the skills and pick interactively:

npx skills add gethamster/skills

Source: gethamster/skills on GitHub, MIT licensed.