retro

name	retro
description	Facilitates a sprint retrospective using Start/Stop/Continue, 4Ls, or Sailboat format, producing 2-3 prioritized action items with owners and deadlines. Use after a sprint or milestone to drive continuous improvement. Triggers on: retrospective, retro, sprint review, what went well, lessons learned, team improvement, action items, start stop continue, post-mortem, sprint reflection.

Retrospective (Retro)

Core Philosophy

A retro that produces no action items is a venting session with good intentions. The measure of a retro is not the quality of the conversation — it's whether anything changed in the next sprint.

Limit action items to 2-3. More than that means none of them will get done. Be specific and assign an owner. "We should improve communication" is not an action item. "Maria will set up a 15-minute daily sync starting Monday" is.

When to Use

• End of every sprint (or bi-weekly if sprints overlap)
• After any significant milestone, launch, or incident
• When team morale or velocity is declining and the cause is unclear
• When the same problems keep recurring sprint after sprint

Workflow

1. Choose a Format

Pick based on team maturity and what the sprint needs:

Start / Stop / Continue (default — versatile, familiar)

• Start: What should we begin doing?
• Stop: What should we stop doing?
• Continue: What's working well that we should keep?

4Ls (for deeper reflection after a major milestone)

• Liked: What did the team enjoy?
• Learned: What new knowledge did we gain?
• Lacked: What was missing?
• Longed For: What do we wish we had?

Sailboat (when team is stuck or unmotivated)

• Wind (propels us): What's driving us forward?
• Anchor (holds us back): What's slowing us down?
• Rocks (risks ahead): What dangers are coming?
• Island (goal): Where are we trying to get to?

2. Review Sprint Performance

Before soliciting feedback, anchor the conversation in data:

• Sprint goal: achieved / partially achieved / missed
• Committed vs. completed story points
• Blockers that arose and how they were resolved
• Notable events (incidents, unplanned work, scope changes)

3. Collect and Group Feedback

If running async or with sticky notes: group similar items into themes. Identify the top 3-5 most mentioned topics. Note sentiment — frustration vs. energy vs. confusion.

If running synchronously: timebox each section (5-7 min per category), then vote on the most important items to discuss.

4. Discuss Root Causes, Not Symptoms

For the top themes, ask "why" twice:

• "We were blocked on the API" → Why? → "We didn't confirm external availability" → Why? → "We didn't include it in sprint planning"

The action item should address the root cause, not the symptom.

5. Define 2-3 Action Items

Each must be:

• Specific: "Add external dependencies to sprint planning checklist" not "communicate better"
• Owned: One named person responsible for doing or driving it
• Time-bound: A deadline or the next sprint date
• Measurable: You should be able to confirm next retro whether it was done

6. Check Previous Retro Actions

Pull last retro's action items. Status each: Done / In Progress / Not Started. If "Not Started" for the second time, either assign a new owner or explicitly drop it.

Output Format

## Retrospective — Sprint [N] — [Date]

### Sprint Performance
- Goal: [Achieved / Partially / Missed] — [one sentence on why]
- Committed: [X pts] | Completed: [Y pts]

### Key Themes
1. [Theme] — [Summary of feedback, root cause]
2. [Theme] — [Summary]
3. [Theme] — [Summary]

### Action Items
| # | Action | Owner | By |
|---|---|---|---|
| 1 | [Specific action] | [Name] | [Date / Next sprint] |
| 2 | [Specific action] | [Name] | [Date] |

### Previous Retro Actions — Status Check
- [Previous action] → [Done / In Progress / Dropped — reason]

Antipatterns

• No action items: The retro felt good but nothing changed. If there's genuinely nothing to improve, you're not looking hard enough.
• Too many action items: 8 action items = 0 action items. Prioritize ruthlessly.
• Vague actions: "Improve communication" or "be more proactive" cannot be completed or measured. Force specificity.
• No owner: Shared ownership is no ownership. Every action item needs one person's name.
• Skipping the previous actions check: This is how retros become theater. If you never review whether last retro's actions were done, teams stop believing the exercise matters.
• Blame framing: A retro focused on who failed rather than why systems failed. Keep the language systemic, not personal.