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.

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

Facilitating a 4Ls sprint retrospective meeting means holding the process so the team can do the thinking. The facilitator decides the agenda and the timeboxes, protects silent writing, keeps discussion on the few themes that matter, and makes sure the meeting ends with commitments. They do not steer the content. The 4Ls method page covers what the four categories mean and where the format came from; this skill covers running the room.

The meeting follows the five phases from Esther Derby and Diana Larsen's Agile Retrospectives: set the stage, gather data, generate insights, decide what to do, and close. The 4Ls fill the gather-data phase. Everything else is the facilitator's job, and most failed retrospectives fail in those other phases: a rushed opening that leaves people guarded, a discussion that wanders, or a close that produces no actions.

A good facilitator watches three things at once. The clock, because a phase that overruns steals time from the decision. Participation, because a retrospective where two people talk reflects two people's view of the sprint. And tone, because blame shuts down honest Lacked notes faster than anything else. The skill is noticing drift in any of the three early and correcting it without making a show of it.

The facilitator can be the Scrum Master, a rotating team member or someone from another team. The requirement is that the team sees them as neutral. GitLab's handbook asks for an impartial moderator and says a moderator who wants to take part should say so explicitly, or hand moderation to a peer. That rule applies to anyone with a stake in the outcome, including a manager.

How It Works

Timing is the main design decision. The Scrum Guide caps the Sprint Retrospective at three hours for a one-month Sprint, and shorter Sprints get shorter retrospectives. For a 4Ls session, published guides converge on about an hour. Atlassian's play budgets 60 minutes of run time for up to eight people, and Retrium describes 30-60 minutes depending on group size.

Retrium's guide to the five phases gives one way to split an hour:

Treat that as a starting point. A team with a hard sprint behind it may need more time generating insights. A small team may finish gathering data quickly.

Silent writing is the facilitator's most important protection. In the original EBG steps, everyone writes notes for each L and posts them silently before any discussion. The reason is anchoring: once someone says "the release was chaotic", later notes tend to echo that framing. Writing first also gives quieter people and newer members an equal voice.

Prioritizing is the second protection. There are usually more themes than time. Dot voting narrows them, and the Nielsen Norman Group's guidance is to vote silently, give people roughly a quarter as many votes as there are options, and let less senior people vote before stakeholders. The facilitator then spends discussion time on the top themes only.

Finally, the facilitator owns the close. Every action leaves with one named owner and a date, and the first agenda item of the next retrospective is checking them.

Step-by-Step Guide

Step 1: Prepare the Session

Book the meeting at the end of the sprint, before planning for the next one, so actions can go straight into the new backlog. Set up the board with the four columns, prompts under each, a parking area and an action area. Gather the facts of the sprint: the goal, what shipped, incidents, and last retrospective's actions with their status. Write your agenda with a timebox per phase and share it in the invite. If the sprint was rough, talk to anyone likely to arrive upset so they are not surprised by the format.

Step 2: Set the Stage

Open by stating the purpose and the scope: this sprint, this team. Read the Prime Directive, or restate it in your own words, so the room agrees to look at conditions rather than individuals. Review last retrospective's actions briefly: done, in progress or dropped, and why. Run a one-word or one-sentence check-in so everyone has spoken once. Explain the four Ls with one example each, paying most attention to the difference between Lacked and Longed For.

Step 3: Run Silent Writing

Start a visible timer and ask everyone to write notes for all four Ls, one idea per note. Keep the room quiet until the timer ends, and answer questions privately if someone is stuck. Ask for notes tied to specific events, and nudge anyone who has written only in one column. When time is up, have people post their notes, or reveal them all at once on a digital board. If the board looks thin in one category, give one extra minute for that column alone.

Step 4: Cluster and Name Themes

Walk the board one column at a time, reading notes aloud or letting people read silently. Group notes that describe the same thing and give each cluster a short name that states the issue. Move notes that sit in the wrong column, and merge duplicates while keeping a count of how many people raised each theme. With a larger team, follow EBG's approach and split into four subgroups, one per L, that each cluster a column and report back. Keep interpretation out of this step; the goal is an accurate map of what people said.

Step 5: Vote on What to Discuss

Explain the voting rules before anyone votes: how many dots, whether stacking is allowed, and that voting is silent. Have everyone vote at once, or on a digital board with other votes hidden until the end. Rank the themes by votes and draw a line under the few that fit the remaining time. Tell the team what happens to the themes below the line: they stay on the record and are reviewed next time. Include Liked and Learned themes in the vote, since protecting a good practice is a legitimate action.

Step 6: Discuss the Top Themes

Take the top theme and ask what caused it, what made it worse and what would change it. Keep asking why until the team can state the cause in one sentence, then move on. Watch participation and invite people who have not spoken by name, gently. When the discussion drifts into a new topic, park it on the board rather than following it. Stop each theme at its timebox even if the conversation is lively, because the decision phase needs its time.

Step 7: Agree on Actions and Owners

Turn each discussed theme into at most one or two actions small enough to finish before the next retrospective. Write each as a concrete step, with one person's name and a due date. Ask the owner to restate the action in their own words so any misunderstanding surfaces now. If a theme is outside the team's control, the action is an escalation with an owner. Put the actions in the sprint backlog or tracker during the meeting, which the Scrum Guide explicitly allows for the most impactful improvements.

Step 8: Close and Document

End with a short round on the retrospective itself: one thing to keep and one to change about the meeting. Thank people for specific contributions, not in general. Within the day, post the board, the themes, the actions and their owners where the team keeps its records. GitLab's handbook asks that every action be assigned with clear expectations for when it will be done, which is the minimum a summary should show. Keep the format the same every time so trends are easy to read later.

Best Practices

• Show a shared timer for every phase. A visible clock makes the timebox the team's agreement rather than the facilitator's opinion, and it removes the need to interrupt someone mid-sentence.
• Rotate the facilitator every few sprints. Rotation spreads the skill across the team, keeps any one person from shaping every retrospective, and gives quieter members a structured way to lead.
• Keep your own opinions out of the room while facilitating. If you have a note to add, write it during silent writing like everyone else and do not advocate for it during discussion.
• Separate facilitating from note-taking. Ask a volunteer to capture themes and actions so you can watch the clock, participation and tone.
• Limit actions to what the team can finish in one sprint. A short list that gets done teaches the team that retrospectives work; a long list that does not teaches the opposite.
• Vary the check-in and prompts every few sprints while keeping the four categories. The structure stays familiar and the answers stay fresh.

Common Mistakes

• Skipping silent writing: Going straight to open discussion lets the first speaker frame the sprint for everyone. Protect the writing phase with a timer and keep the room quiet until it ends, even if people want to talk.
• Ending with themes and no actions: A board full of insights with no owners changes nothing. Never close without at least one concrete action that has a named person and a date, and narrow the scope until someone will take it.
• Letting Lacked take over the discussion: Problems attract attention, so Liked and Learned get skipped. Include them in voting and discussion, because naming what to protect is as useful as naming what to fix.
• Facilitating while holding a stake: A manager or lead who facilitates and argues positions makes it unsafe to disagree. Say explicitly when you are speaking as a participant, or hand facilitation to someone neutral.
• Not checking last time's actions: If the previous actions are never reviewed, people learn that commitments made in the retrospective are optional. Make the review the first agenda item, every time.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: 4Ls Sprint Retrospective

Related Skills

• Building a 4Ls Retrospective Board and Template
• Tracking 4Ls Retrospective Trends Across Sprints
• Sorting Team Feedback into the 4Ls Categories
• Writing 4Ls Retrospective Questions for Each Category
• Turning 4Ls Retrospective Insights into Action Items
• Running a 4Ls Retrospective for Remote and Hybrid Teams

Sources

• Derby, Larsen and Horowitz: Agile Retrospectives, Second Edition
• Retrium: The five phases of a successful retrospective
• Atlassian Team Playbook: The 4 Ls retrospective technique
• EBG Consulting: The 4L's, a retrospective technique
• Nielsen Norman Group: Dot voting
• GitLab Handbook: Group retrospectives
• The Scrum Guide

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