4Ls retrospective template: Liked, Learned, Lacked, Longed For

Four lenses that separate what the team felt, learned, missed, and wished for.

4Ls is a four-column retrospective where the team answers what they Liked, what they Learned, what they Lacked, and what they Longed For. The four prompts pull apart things a two-column retro flattens together: enjoyment is not the same as learning, and a missing tool is not the same as an unfulfilled wish.

It rewards a longer horizon. Over a single sprint the Learned and Longed For columns are thin, but across a milestone, a quarter, or a finished project they are where the useful material is — what the team now knows that it did not before, and what it kept quietly wishing for while it worked.

Timebox

45–60 minutes

Team size

4–12 people

Cadence

End of a milestone, project, or quarter — or every third sprint as a change of pace

The 4Ls board

Liked

What did you enjoy or appreciate about this period?

  • The kickoff workshop — everyone left knowing what we were building
  • Working directly with the support team instead of through tickets
  • The weekly demo, even when there was little to show
  • Having one clear owner per workstream
  • Being trusted to choose the approach rather than being handed a design

Learned

What do you know now that you did not know at the start of this period?

  • The legacy import path handles three formats, not one
  • Our customers batch their work on Mondays — load looks nothing like the average
  • Feature flags cost us less than the release branches they replaced
  • Two hours of user interviews saved a month of building the wrong thing
  • Estimating in half-days is more honest for this team than story points

Lacked

What was missing that we needed — information, tools, time, people, or clarity?

  • A staging environment with realistic data
  • A decision about pricing before we built the billing screens
  • Design capacity in the second half of the project
  • Any monitoring on the new service until week six
  • A named owner for the migration cutover

Longed for

What did you wish for — including things outside our control?

  • A real deprecation window instead of a hard cutover date
  • Fewer parallel projects so we could finish one thing
  • Direct access to customers without going through account managers
  • A second backend engineer from the start
  • A week of nothing but paying down the shortcuts we took

How to run a 4Ls retrospective

  1. 1

    Set the stage and fix the horizon (5 min)

    Say explicitly what period is under review — this project, this quarter, these three sprints. 4Ls falls apart when half the team is reviewing the last two weeks and the other half the last two months.

  2. 2

    Rebuild the timeline (5–8 min)

    For anything longer than a sprint, lay out the milestones, releases, and incidents in order before anyone writes a card. Memory is heavily weighted toward the final two weeks, and a timeline is the cheapest correction for it.

  3. 3

    Silent writing across all four columns (10 min)

    Everyone writes privately with cards hidden. Encourage at least one card per column: Learned and Longed For are the ones people skip, and they are the reason to run this format instead of a two-column retro.

  4. 4

    Reveal, group, and read Learned aloud (8 min)

    Reveal everything and cluster by theme. Read the Learned column out loud in full — it is the part that has value outside the room, and it is worth capturing somewhere more permanent than the board.

  5. 5

    Vote on Lacked and Longed for (3 min)

    Give each person 3–5 votes, spent only on the Lacked and Longed For columns. Those are the two that describe gaps, so they are the ones that can turn into changes.

  6. 6

    Discuss and translate into actions (15–20 min)

    Work the top themes and convert them into two or three owned actions. For Longed For items outside the team’s control, name what the team will ask for and who will ask — that is still an action, and it is better than a wish on a board.

4Ls examples for engineering teams

Liked

  • Trunk-based development with flags instead of long-lived branches
  • The rotating on-call handover call on Mondays
  • Reviewing the architecture decision record before writing code
  • Pairing on the parts nobody had touched in two years

Learned

  • The queue backs up at 40 messages per second, not the 200 we designed for
  • Rollbacks are safe now — we did three without an incident
  • Half our test time is spent on fixtures, not assertions
  • The vendor SDK swallows errors unless you set one undocumented flag

Lacked

  • Dashboards for the new service until well after launch
  • A load-testing environment anyone could actually run
  • Written ownership of the shared libraries
  • Time to finish the migration before the next project started

Longed for

  • A freeze on new dependencies until we upgrade the old ones
  • One sprint with no context switching
  • Enough monitoring budget to keep traces longer than seven days
  • Being consulted on the deadline instead of told

4Ls examples for a project or quarter review

At the end of a project, the four columns turn into a handover document: what to repeat, what the organisation now knows, what was missing, and what to negotiate before the next one starts.

Liked

  • A single stakeholder who could actually make decisions
  • The two-week discovery phase before committing to scope
  • Shipping to a small pilot group before the full rollout
  • Weekly written status instead of a standing meeting

Learned

  • The rollout took three weeks longer than any estimate — mostly on data migration
  • Support volume doubles for two weeks after any UI change
  • Two of the three "must-have" features are barely used
  • Pilot users tell us more in one call than a month of analytics

Lacked

  • A success metric agreed before we started building
  • Any budget for the training the rollout clearly needed
  • A decision on the legacy system’s end date
  • Enough QA time in the final two weeks

Longed for

  • Fewer simultaneous priorities from leadership
  • A proper post-launch period instead of starting the next project immediately
  • Access to the customers who churned, not only the happy ones
  • A published roadmap the team could plan against

4Ls examples for onboarding and new-team reviews

Run 4Ls 30 to 90 days after someone joins, or after a newly formed team’s first month. The Lacked column collects exactly the gaps that are invisible to everyone who has been there a year.

Liked

  • A named buddy for the first two weeks
  • Shipping something small on day three
  • Open access to every repository from the start
  • Recorded architecture walkthroughs I could rewatch

Learned

  • Which service owns which part of checkout
  • That most decisions are made in the design channel, not in meetings
  • How to run the test suite locally without the full stack
  • Who to ask about billing — it is not the billing team

Lacked

  • A glossary — half of every meeting was unfamiliar acronyms
  • Local environment setup that worked without three people helping
  • Clarity about what I was expected to own by month three
  • Any written description of the release process

Longed for

  • More overlap hours with the rest of the team in my first month
  • A written onboarding path instead of a list of links
  • Time to read the code before being assigned to it
  • Introductions to the teams we depend on

Best for

  • End-of-project and end-of-quarter reviews that need more than sprint mechanics
  • Teams whose sprint retros have gone stale and repetitive
  • Onboarding or first-90-days reviews, where Learned is the whole point
  • Cross-functional groups that worked together temporarily and are about to split up

Facilitation tips

Lacked and Longed for are different columns

Lacked is what the team needed and did not have — usually inside its control or its manager’s. Longed for is the wish, including things nobody in the room can grant. Merging them buries the actionable gaps under the wishes.

Learned is the column with value outside the room

It is the only retro output other teams will read. Capture it somewhere permanent — a wiki page, a project write-up, an onboarding doc — before the board is archived and it disappears.

Give it a longer horizon than a sprint

Over two weeks, most people have nothing new to put under Learned or Longed for. Over a quarter or a finished project, those two columns carry the session. Save 4Ls for the moments that deserve it.

Do not let Longed for die on the board

For each top wish, agree what the team will ask for, who asks, and by when. "We wanted more design capacity" becomes an ask with a name on it — which is the only version that ever changes anything.

Variations

Timeline-first 4Ls

Build a shared timeline of the period, then write cards against it. Essential for anything longer than a month, because unaided memory heavily overweights the last two weeks.

Three Ls

Drop Longed For and run Liked, Learned, Lacked when the session needs to stay inside the team’s own control. Faster, and it avoids a column of wishes aimed at people who are not in the room.

Onboarding 4Ls

Run it with one person at 30, 60, or 90 days. The Lacked column becomes an onboarding backlog written by the only person who can still see the gaps clearly.

Async 4Ls

Open the board for two or three days so people can add cards as they remember things — especially useful for a long project — then meet for 30 minutes to group, vote, and decide.

Frequently asked questions

What does 4Ls stand for?+

Liked, Learned, Lacked, and Longed For. The team fills one column for each: what they enjoyed, what they now know, what was missing, and what they wished for — including things outside their control.

What is the difference between Lacked and Longed for?+

Lacked is something the team needed and did not have, and usually could get: a staging environment, a decision, QA time. Longed For is a wish, often outside the team’s control: fewer parallel projects, a different deadline, another engineer. Keeping them apart is what makes the format useful — the Lacked column is where the actionable gaps are.

When should a team use 4Ls instead of a sprint retro format?+

At the end of a milestone, project, or quarter, and after onboarding. The Learned and Longed For columns need a longer horizon than two weeks to produce anything; for a routine sprint retro, a three-column format like Went Well / To Improve or Start Stop Continue gets to actions faster.

How long does a 4Ls retrospective take?+

Plan 45–60 minutes: 5 to set the stage, 5–8 to rebuild the timeline, 10 for silent writing, 8 to group, 3 to vote, and 15–20 to discuss and agree actions. Four columns take longer to fill than three, so do not try to squeeze it into 30 minutes.

Where does the 4Ls retrospective come from?+

The technique is commonly credited to Mary Gorman and Ellen Gottesdiener, who introduced the four Ls as a way to review a project or iteration from several angles at once. It spread through agile practice as a milestone and end-of-project format rather than a weekly one.

Run 4Ls online in FocusRetro

The 4Ls template is built in: pick it when creating a board, invite the team with a link, and run the phases with timers and blind voting. Free plan available at focusretro.com.

Open the template free

No credit card required

Related guides

Went Well / To Improve / Action Items retrospective template

The default sprint retro: two honest columns and a short list of actions somebody owns.

Release retrospective template

The retro for a whole release: timeline first, then the three things that change before the next one.

Rose, Bud, Thorn retrospective template

A gentle, visual format that surfaces wins, problems, and untapped opportunities.

How to run a sprint retrospective (step-by-step guide)

A step-by-step sprint retrospective guide: the 5-phase agenda, exact timings for a 60-minute session, facilitation tactics, remote tips, and common failure modes.

What is a retrospective? The complete guide for teams

A retrospective is a recurring team meeting for inspecting how you work and deciding what to change. Learn the formats, agenda, timings, and mistakes to avoid.

Retrospective timebox calculator

How long 4Ls should run for your sprint length and team size, split across the five phases.

Icebreaker and check-in questions

Openers for the first two minutes of a 4Ls session, sorted by situation.