Retrospectives That Actually Work

Learning Objectives

By the end of this lesson you will be able to:

• Identify three reasons retrospectives stagnate and fail to produce change
• Facilitate the 4Ls, Fishbone, and Start/Stop/Continue formats
• Apply the SMART action item technique to make retro outcomes stick
• Describe how to measure whether a retrospective produced real improvement

Why Retros Stagnate

A retrospective that produces no change is worse than no retrospective. It costs team time, creates false hope, and teaches the team that retrospectives are a performance — not a tool.

Reason 1: The Same Format, Every Sprint "Worked well / Didn't work well / Actions" on sticky notes — every sprint, forever. The team has learned to generate plausible outputs without genuinely reflecting. The sticky notes go on the board; the actions get forgotten; nothing changes.

Reason 2: Actions Without Owners "We should improve our test coverage" sounds like an action. It isn't. An action needs an owner, a definition of Done, and a deadline. Vague commitments are forgotten by Tuesday.

Reason 3: No Follow-up on Previous Actions If you never check what happened to last sprint's actions, the team learns that retro actions are performative, not real. Starting every retrospective by reviewing previous actions is the most important habit for building trust in the process.

Format 1: The 4Ls

4Ls = Liked, Learned, Lacked, Longed For

When to use it: When the team needs a broader emotional register than "good/bad." The "Longed For" category often surfaces aspirational improvements that the team doesn't raise in more critical formats.

How to run it:

1. 5 minutes silent individual writing — each person fills in all four categories
2. Share and cluster on a board (digital or physical)
3. Dot-vote on the most important items
4. Spend remaining time on the top 1-3 clusters, generating specific actions

Why it works: "Longed For" separates complaints from aspirations. Teams often know what they're missing but don't have a format to name it constructively.

Format 2: Fishbone (Cause & Effect)

Also called Ishikawa or Cause-and-Effect diagram.

When to use it: When the same problem keeps appearing across sprints and the team doesn't know why.

How to run it:

1. Write the problem statement in the "fish head" (right side): "We consistently miss sprint goals"
2. Draw 4-6 "bones" representing categories: Process, People, Tools, Communication, Environment, Skills
3. Team brainstorms causes under each category
4. Cluster and identify the root cause(s)
5. Generate one specific action targeting the root cause, not a symptom

Why it works: Surface-level retros generate surface-level actions. Fishbone forces the team to think about why the problem exists, not just that it exists.

Format 3: Start / Stop / Continue

Classic and effective when used with discipline.

When to use it: Sprint health check — suitable for most sprints, especially with newer teams.

How to run it:

1. Everyone writes 2-3 items in each category silently
2. Share, cluster, remove duplicates
3. Ruthlessly prioritize: choose ONE Start, ONE Stop, ONE Continue
4. Make each a SMART action item before the retro ends

The discipline that makes it work: The prioritization step. Most teams skip it and end up with 12 actions — which is functionally zero actions, because nothing gets focused attention.

Making Actions Stick: The SMART Technique

Every retro action must be:

• Specific: "Improve code reviews" → "Reviewer leaves at least one substantive comment per PR"
• Measurable: Can we verify it happened?
• Assigned: One person owns it (not "the team")
• Realistic: Can this actually be done this sprint?
• Time-bound: "Done by the next retro" or "in place from Sprint 23"

Bad action: "We should communicate better."
Good action: "Alice will add a 'Blockers' section to our sprint board and review it each Daily. Starting Monday."

Pro Tip: Never end a retrospective without reading each action aloud and confirming: "Does everyone understand this? Do you agree this is achievable?" Then photograph or export the board — don't trust anyone's memory.

Measuring Retrospective Effectiveness

How do you know if a retrospective worked? Check:

1. Were last sprint's actions completed? (If no: the retro format is fine; the follow-through is broken)
2. Did the team's velocity or quality improve in measurable ways? (Compare sprint metrics before and after the action was in place)
3. Is the team bringing genuine, specific problems to retro? (If retros feel performative, trust is missing)
4. Are actions getting smaller and more specific over time? (Teams that improve learn to target smaller, more precise changes)

Summary

Retrospectives are the mechanism by which a Scrum team continuously improves. When they work, they compound — each sprint slightly better than the last. When they stagnate, they create cynicism that's hard to reverse. The difference between a retro that changes things and one that doesn't is almost always about action quality: specific, owned, followed up on. Format variety helps, but action discipline is what makes the improvement real.