The Agile Retrospective Meeting Template: 5 Formats That Work

A retrospective meeting (retro for short) is a recurring team meeting at the end of a sprint or project phase. The team reflects on what happened, decides what to keep, and commits to what will change next.

‍

It's the smallest unit of continuous improvement in agile, codified in the Scrum Guide by Ken Schwaber and Jeff Sutherland, and echoed in the Agile Manifesto's twelfth principle. In most teams it's also the meeting that quietly loses its edge first.

‍

Most retros don't fail at the format. They fail at the commitment step — the one minute at the end where every decision gets a name, a date, and a tracker. The format you pick matters less than whether you actually run that step.

‍

Why retros go stale?

A retro goes stale in one of three ways.

‍

The first is repetition. Same three complaints every sprint, same silent agreement, nothing changes. The team learns that the retro is where things are said, not where they get fixed.

‍

The second is safety. If the team doesn't feel safe naming real problems, the retro becomes a polite ritual. This is especially true for problems with leadership, a specific person, or a decision the company made. The real conversation happens in side channels. Amy Edmondson's research on psychological safety at Harvard Business School is the underpinning literature here; the Agile Alliance and Mountain Goat Software (founded by Mike Cohn) both cite it in retrospective guidance.

‍

The third is scope creep. The retro turns into a venting session about everything that's wrong with the company, including things the team can't influence. Energy leaks; nothing lands.

‍

Most retro fixes target the format. The more common fix is upstream: whether the team is allowed to say true things, and whether the team's commitments actually track.

‍

What a good retrospective meeting produces

Before picking a format, know what the retro is supposed to leave behind. A healthy retro produces four things:

• A short list of committed changes for the next sprint, with owners and dates
• One celebrated win worth repeating, not just a note-to-self
• A named risk or blocker that wasn't being tracked and now is
• A pulse on how the team is feeling, measurable or felt, but captured

‍

If a retro ends with three of four, it was a good one. If it ends with zero, the format or the facilitation is wrong, not the team.

‍

The 5 retro formats (and when to use each)

No single format fits every team every sprint. The strongest retro facilitators rotate.

1. Start / Stop / Continue

Three columns. What should we start doing? What should we stop doing? What should we continue?

‍

Best for: teams new to retros, or teams that need a fast, clean reset after drama. Runs 30–45 minutes.

‍

Template:

• Start (5–7 min silent input + 10 min group)
• Stop (5–7 min silent input + 10 min group)
• Continue (3–5 min silent input + 5–7 min group)
• Action items (5 min)

‍

When not to use: when the team is stuck in repetition. Start/Stop/Continue is easy to fill with the same items every sprint, which hides the deeper problem.

‍

2. 4Ls: Liked / Learned / Lacked / Longed For

Four prompts. What did you like? What did you learn? What did you feel lacked? What did you long for? The 4Ls format is attributed to Mary Gorman and Ellen Gottesdiener of EBG Consulting.

‍

Best for: end of a project phase, a quarter, or a major initiative. Good at surfacing team growth and career signal, not just process friction.

‍

Template:

• Silent input for each L (3 min each)
• Group discussion, one L at a time (7–10 min each)
• Action items (5 min)

‍

When not to use: routine mid-sprint retros. 4Ls takes emotional energy that doesn't recharge every two weeks.

‍

3. Mad / Sad / Glad

Three emotions. What made you mad? What made you sad? What made you glad?

‍

Best for: teams coming off a hard sprint or incident. Permission to name frustration directly without dressing it up as process language.

‍

Template:

• Silent input per emotion (3–5 min each)
• Group, one emotion at a time, with a no-debate rule on naming (7–10 min each)
• What do we want to do about it? (10 min)

‍

Watch the safety dynamics here. The Mad column can either unstick a team or harden a grudge, depending on the facilitator. If your team is newly formed or already fragile, choose a different format until trust is established.

‍

4. Sailboat

A visual metaphor. Draw a sailboat on a shared board (Miro, Mural, FunRetro, Retrium, EasyRetro, Parabol, or a whiteboard on Zoom or Google Meet). The sail is the wind (what's pushing us forward). The anchor is what's holding us back. The rocks are risks ahead. The island is the goal we're sailing toward. The Sailboat retrospective is associated with Luke Hohmann's Innovation Games methodology.

‍

Best for: teams that respond better to visuals than lists, or teams that need to talk about strategic direction, not just the last sprint.

‍

Template:

• Set the island (the goal) at the top, 2 min group alignment
• Silent input across wind, anchor, rocks (10 min)
• Group discussion, one element at a time (10–15 min)
• Action items, framed as "how do we raise the sail / cut the anchor / avoid the rocks?" (5–7 min)

‍

When not to use: teams that find metaphors annoying. Some teams love Sailboat; others find it twee. Read the room.

‍

5. DAKI: Drop / Add / Keep / Improve

Four buckets. What should we drop entirely? What should we add? What's working that we should keep? What's almost working that we should improve?

‍

Best for: mature teams where the discussion is already specific. DAKI forces commitment in a way Start/Stop/Continue sometimes doesn't. You're not just starting something, you're adding or dropping it.

‍

Template:

• Silent input for each bucket (3 min each)
• Group discussion (8 min each)
• Vote on the top 1–2 per bucket (5 min)
• Action items (5 min)

‍

When not to use: teams that haven't yet agreed on their core practices. DAKI assumes a baseline to drop or improve from.

‍

How to rotate formats across a quarter

A practical rotation that keeps retros fresh across a 6-sprint quarter:

• Sprint 1: Start/Stop/Continue (fast, low-stakes reset)
• Sprint 2: Start/Stop/Continue (spot patterns across sprints)
• Sprint 3: DAKI (force commitment)
• Sprint 4: Sailboat (zoom out to strategic direction)
• Sprint 5: Mad/Sad/Glad or ESVP (Explorer, Shopper, Vacationer, Prisoner) for an emotional check-in mid-quarter
• Sprint 6: 4Ls (quarter-end reflection)

‍

The point of rotation isn't novelty for its own sake. Different formats surface different signal. A team that only ever runs Start/Stop/Continue sees 30% of what's there. Scrum teams working inside Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Scrum@Scale, or a Kanban setup should also rotate at the program level (the SAFe Inspect & Adapt ceremony plays the same role at the program increment).

‍

The missing 10%: commitment and ownership

Here's the piece most retros skip, and why most retros don't change anything.

‍

A retro that ends with "we should do X" without a name and a date attached is a retro that didn't end. You had a discussion. You did not make a decision. Martin Fowler and the Pragmatic Bookshelf's Agile Retrospectives (Esther Derby, Diana Larsen) have been pointing at this gap since 2006.

‍

The missing 10% is the commitment step. Before anyone leaves the room:

• Every action item has one owner (not two, not a team, one person)
• Every action item has a decide-by or deliver-by date
• Every action item is either going into the team's task tracker (Jira, Linear, ClickUp, Asana, or Azure DevOps) in the next 10 minutes or is not a real commitment

‍

Retros without this step are how teams end up discussing the same three complaints for six months. Retros with it turn into the most valuable 45 minutes of the sprint.

A useful discipline: cap the team at three action items per retro. Teams that commit to ten commit to none. Three is enough to move the needle; ten is a wish list.

‍

The one question that fixes a stale retro

When a retro has gone flat (same people, same complaints, no energy), ask this:

‍

"What's a thing we're all aware is broken, but nobody has named yet because it would be uncomfortable to name?"

‍

Then wait. Don't fill the silence. The first answer is usually the real answer.

‍

This question works because it gives the team explicit permission to name the elephant. Most retros fail because the team is avoiding something. That something is a person, a decision, or a priority. The format is giving them plausible cover. Asking directly removes the cover.

‍

Not every retro needs this. A healthy team working on healthy problems can run Start/Stop/Continue forever. But the first time a retro feels hollow, this is the unlock.

‍

Running retros in remote and hybrid teams

Remote retros demand more deliberate silence than in-person ones. The dominant voice wins faster on a video call (Zoom, Google Meet, Microsoft Teams, Webex). Three adjustments:

• Silent input first, always. Every format starts with individual written input in a shared board before any discussion.
• Round-robin, not volunteer. When moving to discussion, go around the screen in order rather than taking volunteers. Otherwise you hear from the same three people every sprint.
• Write the decisions in the same doc. No side notes, no "I'll send a recap later." If it's not in the shared doc by the end, it didn't happen.

‍

Record the retro. Not to police anyone. Do it to preserve the decisions and the reasoning. Three audiences use the recording: the team member on PTO, the new hire who joins next sprint, and the future retro where someone asks "wait, didn't we already decide this?"

‍

For hybrid retros (some in the room, some remote), put everyone on their own laptop. That rule applies even to the people physically in the room. The asymmetry between "the room" and "the remote attendees" is the single biggest silencer of remote team members. Parity of presence beats quality of room setup.

‍

The role of the facilitator

A retro facilitator is doing four things at once, usually without announcing any of them:

• Keeping the conversation on track without being a cop
• Pulling in the quiet voices without putting anyone on the spot
• Redirecting venting into actionable discussion
• Enforcing the commitment step even when the team is out of energy

‍

The best facilitators rotate the role across the team. The worst facilitator is a manager who sits in the retro every sprint. The team can't name manager-related problems. The facilitator can't safely call out scope creep. If a manager is part of the team doing the work, they facilitate sometimes. If they're above the team, they attend rarely and never facilitate. In Scrum, the Scrum Master is the default facilitator; in Kanban, it's whoever owns the flow, often a team lead or tech lead.

‍

The retro follow-up that separates change from theatre

Within 24 hours of the retro, the facilitator should:

• Post the action items in the team's tracker with owners and dates
• Pin the retro summary in the team channel
• Add a standing 2-minute slot to the next retro titled "How did last sprint's commitments go?"

‍

That last one is the single biggest lever for making retros matter. If the team knows every retro opens with a check on the last one's commitments, commitments get taken seriously. If nobody ever checks, they don't.

‍

Teams that practice this develop a useful habit: the first two minutes of every retro read like a dry stand-up, and the rest of the meeting is better for it.

‍

How MeetGeek automates the retro admin

The retro itself is a human event. The admin around it is exactly the kind of recurring work AI is built for. That admin includes capturing action items, routing them into Jira, Linear, ClickUp, Asana, or Azure DevOps, pinging owners about their commitments, and pulling last sprint's items forward into next sprint's check.

MeetGeek's Meeting Agent joins the retro from your calendar, produces a structured summary with action items extracted and assigned to the right owners, and routes them into your task tracker. A sprint later, when the team asks "how did last retro's commitments go?", the answer is available without anyone digging through a Notion doc.

‍

Ask AI Chat inside MeetGeek for "what did we decide in the last retro?", or pair MeetGeek with Claude through the MeetGeek connector to run Claude's full reasoning over a quarter of retros. This is useful for engineering leaders tracking patterns across multiple teams, or for founders watching how a team's conversations shift over time. The connector is the stronger option for cross-sprint synthesis.

‍

The bottom line for engineering and delivery leaders

A retro is working when three things land every sprint: a short list of committed changes with names and dates, a visible track record that last sprint's commitments shipped, and a team that feels safe naming the real problem. Format matters less than that — Start/Stop/Continue, 4Ls, Sailboat, DAKI, and Mad/Sad/Glad each surface different signal, but none of them save a retro where commitments don't track. Pick the format that fits where the team is. Run the commitment step every time.

‍

If your team is small and the retro admin is already light, a shared doc and a manual tracker hand-off works fine. If you're running retros across multiple squads and last sprint's commitments are getting lost, a meeting intelligence platform like MeetGeek is the more effective choice. Try MeetGeek for free and see how every retro's action items land in Jira, Linear, or your tracker of choice without anyone copying them by hand.

‍

‍

Frequently Asked Questions

‍

How long should a retrospective meeting be?‍

Most retros run 45–60 minutes for a two-week sprint. Under 30 minutes and you skipped the commitment step. Over 75 minutes and you're running planning inside the retro. That belongs in a separate meeting.

‍

Who should attend a retrospective?‍

The delivery team: engineers, designers, product owner, scrum master or team lead. Managers above the team should usually not be in the room, because their presence changes what the team is willing to say. Exceptions: an explicit team decision to invite them.

‍

How often should a team run retros?‍

Every sprint if you're running sprints. For longer cycles, every 2–4 weeks. Skipping retros because "nothing major happened" is the leading indicator that a retro has quietly become performative.‍

‍

What's the difference between a retrospective and a post-mortem?‍

A retro is recurring, covers the whole sprint or period, and is forward-looking (what we'll change). A post-mortem is triggered by an incident, focuses narrowly on that event, and produces a root cause analysis. Different meetings, different outputs.

‍

How do you get honest feedback in a retro?‍

Three things: silent written input first, leadership absent, and a visible track record that last retro's commitments actually happened. Honesty is earned over time, not declared in a ground rule.

‍

What do we do when the same complaint comes up every sprint?‍

Stop treating it as a retro item and escalate it. If the team has raised the same issue three sprints in a row with no change, the retro isn't the right venue. A direct conversation with the person or team that can fix it is. The retro's job is surfacing, not escalating on repeat.

‍

Can AI run a retrospective?‍

No, and it shouldn't. The value of a retro is in the team's reflection and commitment. AI is useful for the admin around it: capturing action items, routing them, and tracking whether last sprint's commitments landed. The meeting itself is human.

‍

How do we measure if our retros are working?‍

Track two things over a quarter: the percentage of retro action items that actually shipped in the next sprint, and how the team answers "do our retros change anything?" in an anonymous survey. If the first number is under 50% or the second is "no", change the format before changing anything else.