← Back to blog

Retrospectives that drive real action

scrum retrospective agile

How many retrospectives has your team held where the same action items get repeated sprint after sprint, never actually implemented? If the answer is “too many to count,” this article is for you.

Why retrospectives fail

  • Too many action items — the team defines 5-6 improvements but only manages to deliver one
  • Vague actions — “improve communication” is not actionable
  • No owner — nobody is personally responsible for following through
  • No follow-up — nobody checks whether the action was actually implemented
  • Lack of psychological safety — the team holds back because they fear consequences for speaking up

Effective format: less is more

Golden rule: maximum 2 action items per retrospective

Fewer actions means a higher chance of follow-through. It’s far better to implement 2 changes per sprint than to list 10 that never leave the whiteboard.

Anatomy of an actionable item

Each action should have:

  • What — a specific, measurable action
  • Who — a person responsible for ensuring it gets done
  • When — a deadline within the current sprint
  • How to measure — a metric or signal that confirms it worked

Bad example: “Improve code quality” Good example: “João will create and roll out a PR checklist by Wednesday. Success metric: 100% of PRs in the next sprint will have the checklist completed.”

Retrospective techniques to rotate through

1. Start, Stop, Continue (the classic)

Simple and functional, but limited. Use it when the team needs a quick retro.

2. 4 Ls — Liked, Learned, Lacked, Longed for

  • Liked: What did we enjoy this sprint?
  • Learned: What did we learn?
  • Lacked: What was missing?
  • Longed for: What do we wish for next time?

3. Sailboat

  • Wind (enablers): What pushed us forward?
  • Anchor (blockers): What held us back?
  • Rocks (risks): What could go wrong ahead?
  • Island (goal): Where are we headed?

4. Happy, Sad, Confused

Each team member places sticky notes into one of three categories. Great for new teams or after a rough sprint.

5. Data first, opinions second

Before opening the floor, present the sprint’s data: velocity, bug counts, estimates vs. actuals. This grounds the discussion in facts rather than feelings.

Psychological safety

Without it, the retrospective is just theater. To build safety:

  • Anonymous input when needed — use tools that allow anonymous submissions
  • Neutral facilitator — the Scrum Master, not the team’s manager
  • No retaliation — what’s said in the retro stays in the retro
  • Leader vulnerability — when the tech lead owns up to mistakes, the team feels safe to do the same

Follow-up: the forgotten step

At the start of each retrospective:

  1. Review last sprint’s action items — were they completed? Did they work?
  2. Celebrate what landed — recognition drives motivation
  3. Drop what’s unviable — if an action hasn’t happened in 2 sprints, it probably won’t

Conclusion

Retrospectives that drive real action are focused, concrete, and followed up on consistently. If your team feels like they’re sitting through “yet another retro,” the issue is likely vague action items or a lack of follow-through discipline. Start with 1-2 actions per sprint and build the habit of actually executing what gets decided.