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.

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

The four words Liked, Learned, Lacked and Longed For are prompts in themselves, and for an experienced team they may be enough. For most teams, one or two well-written 4Ls retrospective questions under each heading make a noticeable difference. They tell people what kind of note belongs in each column, pull out specific events instead of general moods, and reduce the time spent re-sorting notes later. This skill covers writing those questions and adjusting them each sprint.

The original EBG technique uses the four words directly: each person writes what they liked, learned, lacked and longed for. Later guides add questions. FunRetrospectives suggests "What aspects of our work did you really enjoy?" for Liked, "What insights have you gained recently?" for Learned, "What areas do you think the team could improve?" for Lacked and "What changes or additions do you hope for in our team dynamic?" for Longed For. Those are good defaults. Questions tuned to what actually happened in the sprint are better.

Good questions are specific without being leading. "What slowed you down during the payment release?" points at an event and leaves the answer open. "Didn't the payment release go badly?" presumes the answer. The method page covers what each category is for; this skill turns that into words people respond to.

How It Works

A question works when it narrows attention to a time, an event or a kind of experience, and leaves the content to the person answering. Three properties matter most.

It is concrete. "What would you want to do again next sprint?" is easier to answer than "What did you like?" because it points at a behavior. Concrete questions produce notes like "pairing on the migration", which can be acted on, instead of "good vibes".

It is open. Questions that can be answered yes or no, or that assume a conclusion, shut down the answers the team most needs. Start questions with what, which or when. Avoid why at the writing stage, since it tends to trigger defensiveness; save it for discussion.

It is safe. Lacked and Longed For questions ask people to name problems, which is risky if the team feels exposed. Frame them around conditions and resources, not people: "What was missing that would have helped?" rather than "Who dropped the ball?" Norm Kerth's Prime Directive, which assumes everyone did the best job they could with what they had, is the stance these questions should reflect.

Each category needs a different angle:

Tune the set each sprint. After a sprint with an incident, add a Learned question about it. After a quiet sprint, ask about small frictions that normally get ignored. Keep one stable question per category across sprints, so answers remain comparable over time, and rotate one around it.

Finally, keep the set short. One or two questions per category is enough. A long list turns silent writing into a questionnaire and makes people answer the easiest questions only.

Step-by-Step Guide

Step 1: Review the Sprint Before Writing

Look at what happened: the sprint goal and whether it was met, what shipped, incidents, scope changes, people joining or leaving, and last retrospective's actions. Note two or three events that are likely to be on people's minds. Check the notes from the last few retrospectives for recurring themes. This takes a few minutes and is what makes the questions specific. Questions written without looking at the sprint end up generic.

Step 2: Write the Liked Questions

Aim at behaviors and practices worth repeating, not just outcomes. Start from a default such as "What would you want us to do again next sprint?" and add one tied to an event: "What helped most during the launch week?" Avoid questions that invite praise for individuals only, since those are hard to turn into team practices. Keep them short enough to read at a glance. Check that each can be answered with a specific example.

Step 3: Write the Learned Questions

Aim at new knowledge and surprises, technical or not. "What surprised you this sprint?" and "What do you know now that you wish you had known at the start?" both work. If the sprint included something new, like a tool, a customer conversation or an incident, ask about it directly. Learned is the category most often left thin, so a pointed question here pays off. Avoid questions that lead to lessons already known to everyone.

Step 4: Write the Lacked Questions

Aim at missing conditions, not at people. "What was missing that would have helped?" or "Where did you wait on something?" keep the focus on the environment. Name a category of resource if it helps: information, access, time, tools, people. Avoid who-questions entirely at the writing stage. Read the question as someone who had a hard sprint and check that it does not feel like a trap.

Step 5: Write the Longed For Questions

Aim at wishes for the next sprint or beyond. "If you could change one thing about how we work, what would it be?" invites a proposal rather than a complaint. Add a line that clarifies the difference from Lacked: Lacked looks back, Longed For looks ahead. Ben Linders notes that Longed For sometimes surfaces wishes a colleague can grant immediately, so encourage small wishes as well as large ones. Avoid framing that implies every wish will be granted.

Step 6: Calibrate for the Team's State

Adjust the tone to what the team is carrying. After a hard sprint, soften Lacked questions and add an explicit safety line on the board. With a new team, keep questions simpler and closer to the four words. With a mature team that gives the same answers every sprint, sharpen questions toward specific events or a single theme. If trust is low, consider anonymous notes along with gentler questions.

Step 7: Finalize and Place the Questions

Pick one or two questions per category and put them at the top of each column on the board. Read them aloud during the opening and give one example answer for the trickiest category. Watch during silent writing for columns that stay empty, which usually means the question was unclear. After the retrospective, note which questions produced useful notes and which did not. Keep a small library of questions that worked, grouped by category.

Best Practices

• Keep one stable question per category across sprints. Stable questions make answers comparable over time, which helps when someone looks for trends.
• Ask about behaviors, not feelings alone. "What should we keep doing?" produces notes that can become actions; "How did you feel?" is better as a check-in.
• Tie at least one question to an actual event from the sprint. Event-specific questions produce the most specific and useful notes.
• Keep questions short enough to read in a glance. People look up at the board while writing and should not have to parse a paragraph.
• Test Lacked questions for blame. Read them as the person most likely to feel criticized and rephrase anything that points at people.
• Keep a library of questions that worked. A small, tested set saves preparation time and improves with each retrospective.

Common Mistakes

• Leading questions: "Didn't the handoff to QA go badly?" tells people what to write. Rephrase as an open question about the handoff.
• Too many questions: A long list per column turns silent writing into a survey and people answer only the easiest ones. Use one or two per category.
• Generic questions every sprint: The same abstract prompts produce the same abstract answers. Add at least one question tied to this sprint's events.
• Lacked questions that invite blame: Asking what went wrong "with the handoff from design" can land as an accusation. Ask what was missing, not who was missing.
• Ignoring Learned: Teams often leave Learned with a weak prompt and it fills with platitudes. Give it a pointed question about surprises or new knowledge.

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
• 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
• FunRetrospectives: 4 Ls
• Retrospective Wiki: The Prime Directive
• 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.