4Ls Sprint Retrospective: Liked, Learned, Lacked, Longed For

Created by Mary Gorman and Ellen Gottesdiener - https://ebgconsulting.com/blog/the-4ls-a-retrospective-technique/

Overview

The 4Ls sprint retrospective asks a team four questions about the period that just ended: what they Liked, what they Learned, what they Lacked, and what they Longed For. Each person writes answers on their own, the team posts them under the four headings, small groups look for themes, and the whole team decides what to do with them. The four words are easy to remember, which is part of why the format has spread from software teams to training debriefs and management groups.

Mary Gorman and Ellen Gottesdiener of EBG Consulting published the technique in their June 2010 write-up. They describe it as a way to elicit feedback, share it collectively, and explore action possibilities, and they apply it to iteration and project retrospectives as well as to training classes and conference sessions. It began as a variation of the World Café, in which different areas of a room each hold one topic. They normally use all four Ls. When Mary Gorman later mentioned a three-L variation (Liked, Lacked, Longed For) at a Deep Agile event, it spread online, and the authors advise that whichever set a team uses, it keep Longed For, which they say can provide some very powerful data.

Each category does a different job. Liked names what worked, so the team knows what to protect. Learned captures technical and interpersonal discoveries before they fade. Lacked looks back at what was missing: information, people, tools, time. Longed For looks forward at what the team wishes it had, which often turns a complaint into a proposal. Ben Linders, who has used the exercise with Scrum, Kanban and non-software teams, writes that the words steer people toward thinking about possibilities instead of blaming each other.

Compared with Start, Stop, Continue, the 4Ls ask for observations before decisions. Parabol describes the difference as more neutral, far-reaching feedback aimed at fact-finding over immediate solutions. That makes the 4Ls a good fit after a large change, or when a team suspects something is off but cannot yet name it. It is a weaker fit when the team already knows the problem and needs to choose between fixes.

The 4Ls cover the data-gathering part of a retrospective, so they sit inside a larger meeting structure. The one most teams use comes from Esther Derby and Diana Larsen's book Agile Retrospectives: set the stage, gather data, generate insights, decide what to do, and close. The four Ls fill the gather-data phase. Clustering and voting generate insights. Action items are the decision. A facilitator who knows which phase they are in can tell when the team is ready to move on.

In Scrum, the 4Ls are one way to run the Sprint Retrospective, whose purpose the Scrum Guide gives as planning ways to increase quality and effectiveness. The guide caps the event at three hours for a one-month Sprint and expects shorter Sprints to have shorter retrospectives. It also allows the most impactful improvements to go straight into the next Sprint Backlog, which is where 4Ls action items belong if they are going to happen.

The method on this page covers the whole cycle: preparing a board and prompts, facilitating the session, sorting ambiguous notes, turning themes into actions, adapting the format for distributed teams, and reading trends across many retrospectives. If you keep your retrospective history and action items in Hamster, the trend work in the last skill has a single record to read from.

Core Principles

Liked: Name What to Keep

Liked is where the team records practices and outcomes worth repeating. Naming them matters because a practice that nobody mentions is easy to drop under deadline pressure. Good Liked notes are specific enough to repeat: "pairing on the migration script" rather than "good teamwork". The category also sets a constructive tone, since the session opens on what went right.

Learned: Capture Knowledge Before It Fades

Learned turns each iteration into an explicit learning record. Parabol's 4Ls template treats it as knowledge gained by individuals or the team, technical or not. A Learned note can become documentation, an onboarding item or a change to the definition of done. If nobody acts on Learned items, they vanish with the sticky notes.

Lacked: Describe the Gap, Not the Person

Lacked asks what was missing, which points attention at the environment rather than at colleagues. That framing makes it safer to raise missing requirements, unavailable reviewers or a flaky test environment. Norm Kerth's Prime Directive states the assumption behind it: everyone did the best job they could with what they knew and had at the time. A Lacked note that names a person usually needs rewriting before it is discussed.

Longed For: Turn Wishes into Proposals

Longed For looks forward. Where Lacked says "we had no staging data", Longed For says "a seeded staging database for every branch". The EBG authors ask teams not to drop it, and Ben Linders reports that it sometimes surfaces a wish a teammate can grant on the spot. It is also the category most likely to reach outside the team, so the facilitator should expect some items to need escalation.

Write Alone, Then Share

The original 4Ls, and the widely used guides that copy it, start with individual, silent writing before anyone speaks. The EBG write-up has each person write a note per L and post it silently. Writing first gives quieter people and newer members the same airtime as the loudest voice, and it keeps the first comment from anchoring everyone else. Discussion comes after the board is full.

Safety Comes Before Candor

Honest Lacked and Longed For notes depend on people believing they will not be punished for them. Google's research on its own teams ranked psychological safety first among the dynamics that set effective teams apart. In a retrospective that means no blame language, no managers taking notes on individuals, and an agreement about what leaves the room. When safety is low, anonymous input and a neutral facilitator matter more than any prompt.

End with Owned Actions

A retrospective that ends with themes and no commitments teaches the team that the meeting changes nothing. The Scrum Guide expects the most helpful changes to be addressed as soon as possible, and allows them into the next Sprint Backlog. Each action needs one named owner, a concrete first step and a date, and the next retrospective opens by checking it.

Steps

1. Prepare the board and the prompts Set up four areas labelled Liked, Learned, Lacked and Longed For, on posters, a whiteboard or a digital board. Add one or two prompt questions under each heading so people know what belongs there. Pull the facts of the iteration into view: the sprint goal, what shipped, incidents, and the open action items from last time. Decide the timebox in advance; Atlassian's version of the play budgets an hour for a group of up to eight. Invite the whole team, and decide ahead of time whether anyone outside it should attend.

2. Set the stage Open by stating the purpose and the scope of the retrospective, then review last retrospective's action items and their status. Read or restate the Prime Directive so the room agrees to look at systems and conditions rather than at individuals. A short check-in, one word or one sentence from each person, gets everyone speaking early. Explain the four categories with one example each, especially the difference between Lacked and Longed For. This is the first phase in Derby and Larsen's structure, and skipping it is the usual reason later phases stall.

3. Write individually and post silently Give everyone a few minutes to write notes for each L on their own, one idea per note. In the original EBG steps, participants write for 3-4 minutes and post their notes without talking. Keep the room quiet until the timer ends, since early discussion pulls later notes toward whatever was said first. Ask for specific notes tied to events in the iteration. If a note fits two categories, the writer picks one and the team can move it later.

4. Cluster and find themes Read the notes aloud or let people read the board, then group notes that describe the same thing. EBG splits the room into four subgroups, one per L, so each group reads its poster, clusters it and names the themes, then reports back. Smaller teams can cluster together in one pass. Name each cluster with a short phrase that states the issue, such as "release checklist unclear". Move miscategorized notes now and merge duplicates, keeping a count of how many people raised each theme.

5. Choose what to discuss There are usually more themes than time, so the team picks the few that matter most. Dot voting is the common tool; the Nielsen Norman Group suggests giving each person about a quarter as many votes as there are options and voting silently. Spend the discussion time on the top themes, asking what caused them and what would change them. Keep Liked and Learned themes in the discussion, since protecting a good practice is also an action. Stop discussing a theme once the team can state its cause in one sentence.

6. Decide on actions and owners Turn the top one or two themes into actions small enough to finish before the next retrospective. Write each as a concrete step with one named owner and a due date, and put it where the team tracks its other work. The Scrum Guide allows these improvements into the next Sprint Backlog, which keeps them visible during the sprint. If a theme is outside the team's control, the action is an escalation with a named owner. Drop themes that nobody will own rather than recording them as intentions.

7. Close and follow through End with a quick round on the retrospective itself, so the facilitator learns what to change next time. Record the board, the themes, the actions and their owners in the team's usual place within the day. GitLab's handbook asks that every action be assigned with clear expectations for when it will be done. Keep the record in a consistent format, because the next retrospective starts from it. Over several iterations, those records show which themes keep coming back.

When to Use

• At the end of a sprint or iteration when the team wants a balanced look at both what worked and what was missing, since the four categories cover both without forcing a verdict.
• After a large change such as a new tool, reorganization or release process, when the team needs to gather observations before it knows what to fix.
• For a project or release retrospective, where Learned captures knowledge the next project can reuse.
• With non-software groups, training classes or events, which the EBG authors and Ben Linders both describe using it for.
• When a team has run the same format so often that answers have gone stale, since the four prompts pull out different material from Start, Stop, Continue.

When Not to Use

• After an incident that needs a timeline and root-cause analysis, where a structured post-incident review answers the question better than four open categories.
• When trust is low enough that people will not write honest Lacked notes, even anonymously. Fix the safety problem first, with a neutral facilitator or a smaller session.
• When the team already knows its main problem and needs to choose between solutions, where a decision-focused format moves faster.
• When nobody has the time or authority to act on the results, because collecting feedback that goes nowhere erodes trust faster than skipping the meeting.

4Ls Compared with Related Formats