{{PREAMBLE}}

Sprint Retrospective Mode

Philosophy

A retrospective that doesn't change behavior is a waste of an hour. Most retros fail not because the team doesn't identify problems — they fail because the actions are vague ("communicate better"), no one owns them, and nobody follows up.

The #1 retro failure: Retro theater. The team lists things that went well and didn't go well, nods solemnly, and changes nothing. The same problems appear in the next retro. And the next. And the next.

The #2 retro failure: Blame sessions. Retros that turn into "who screwed up" instead of "what can we change." The facilitator's job is to keep focus on systems and processes, not individuals. "The deploy failed" is a system problem. "Dave pushed broken code" is a blame problem — and it's also a system problem (where was the CI check?).

The #3 retro failure: Too many actions. Five action items means zero action items. Pick the top 1-2 changes that will have the most impact. Do those. Then pick the next 1-2.

Format Selection

Ask the user (via AskUserQuestion):

What retro format fits this sprint?

RECOMMENDATION: Choose A (Start/Stop/Continue) for most sprints — it's action-oriented and familiar. Choose D (Sailboat) if the team needs to think more strategically about direction.

A) Start/Stop/Continue — What should we start doing, stop doing, and keep doing? (Most common, action-oriented) B) 4Ls — Loved, Learned, Lacked, Longed For (Good for reflecting on both wins and gaps) C) Mad/Sad/Glad — Emotional temperature check (Good when team morale needs attention) D) Sailboat — Wind (helps), Anchors (slows), Rocks (risks), Island (goal) (Good for strategic thinking) E) Custom — I have a different format in mind

Step 1: Sprint Context

Before diving into the retro, establish what happened.

SPRINT CONTEXT
══════════════
Sprint: [Name/Number] — [Start date] to [End date]
Sprint Goal: "[The goal from sprint planning]"
Goal Met: Yes / Partially / No

SPRINT SCORECARD:
| Metric | Planned | Actual | Notes |
|--------|---------|--------|-------|
| Stories committed | [N] | [N] completed | [N carried over] |
| Story points committed | [N] | [N] completed | |
| Stretch items pulled | [N] | [N] completed | |
| Bugs found | — | [N] | [Severity breakdown] |
| Blockers encountered | — | [N] | [Avg resolution time] |

Ask the user (via AskUserQuestion):

Before we start the retro, help me understand the sprint outcome.

RECOMMENDATION: Choose A for a quick summary. Choose B if you want a thorough analysis.

A) Quick summary — tell me the sprint goal, whether it was met, and any notable events B) Detailed input — I'll walk you through what happened day by day C) Import from tools — point me to the sprint board or status update

Step 2: Gather Input (by format)

Start/Stop/Continue

START (things we should begin doing):
─────
1. [Practice/behavior] — Why start: [What problem this solves]
2. [Practice/behavior] — Why start: [What improvement this drives]

STOP (things we should stop doing):
────
1. [Practice/behavior] — Why stop: [What pain this causes]
2. [Practice/behavior] — Why stop: [Cost of continuing]

CONTINUE (things that are working — keep doing them):
────────
1. [Practice/behavior] — Why it works: [Specific impact]
2. [Practice/behavior] — Why it works: [Specific impact]

4Ls

LOVED (highlights — what went really well):
─────
1. [Thing] — Impact: [Why this mattered]
2. [Thing] — Impact: [Why this mattered]

LEARNED (new insights — what we discovered):
───────
1. [Insight] — Implication: [How this changes our approach]
2. [Insight] — Implication: [How this changes our approach]

LACKED (gaps — what was missing):
──────
1. [Gap] — Impact: [What suffered because of this]
2. [Gap] — Impact: [What suffered because of this]

LONGED FOR (wishes — what we want but don't have):
──────────
1. [Wish] — Value if addressed: [What improves]
2. [Wish] — Value if addressed: [What improves]

Mad/Sad/Glad

MAD (frustrated — things that caused real frustration):
───
1. [Frustration] — Root cause: [Why this happened, not who caused it]
2. [Frustration] — Root cause: [Why this happened]

SAD (disappointed — things that didn't go as hoped):
───
1. [Disappointment] — Expected vs. actual: [The gap]
2. [Disappointment] — Expected vs. actual: [The gap]

GLAD (positive — things that went well or felt good):
────
1. [Win] — Why this matters: [Impact on team/product/users]
2. [Win] — Why this matters: [Impact]

Sailboat

                    🏝️ ISLAND (our destination)
                    [Sprint/team goal — where we're trying to get]

    💨 WIND (pushing us forward)          ⚓ ANCHOR (holding us back)
    ─────────────────────────            ───────────────────────────
    1. [Tailwind] — Effect: [___]        1. [Drag] — Effect: [___]
    2. [Tailwind] — Effect: [___]        2. [Drag] — Effect: [___]

                    🪨 ROCKS (risks ahead)
                    ───────────────────────
                    1. [Risk] — If we hit it: [___]
                    2. [Risk] — If we hit it: [___]

Step 3: Theme Analysis

After gathering input, identify patterns:

THEME ANALYSIS
══════════════
Theme 1: [Name — e.g., "Communication gaps between frontend and backend"]
├── Evidence: [Items from the retro that point to this theme]
├── Frequency: [First time / Recurring — seen in N of last M retros]
├── Root cause: [Why this keeps happening — system/process issue, not people]
└── Impact: [High/Med/Low — how much does this affect delivery?]

Theme 2: [Name]
├── Evidence: [Items]
├── Frequency: [First time / Recurring]
├── Root cause: [Why]
└── Impact: [Level]

POSITIVE THEMES (what's working — protect these):
Theme 3: [Name — e.g., "Pair programming on complex stories"]
├── Evidence: [Items]
└── Recommendation: Keep doing this. [Why it works.]

Recurring theme alert: If a theme has appeared in 2+ retros, flag it:

⚠️ RECURRING THEME: [Theme name]
   Appeared in: [N] of last [M] retros
   Previous actions taken: [What was tried before]
   Why it persists: [The actions didn't address the root cause / weren't followed up]
   Escalation needed: [Yes/No — does this need leadership attention?]

Step 4: Action Items

The two-action rule: Commit to at most 2 action items. Fewer is better. Each must be specific, owned, and time-bound.

ACTION ITEMS
════════════
ACTION 1: [Specific, measurable action — not "communicate better"]
  Owner: [Single person — not "the team"]
  Due: [Specific date or "by next sprint planning"]
  Success looks like: [How we'll know this action had impact]
  Theme addressed: [Which theme from Step 3]

ACTION 2: [Specific, measurable action]
  Owner: [Single person]
  Due: [Specific date]
  Success looks like: [Observable change]
  Theme addressed: [Which theme]

PARKING LOT (valid but deferred — revisit next retro):
1. [Item] — Why deferred: [Not highest impact / depends on Action 1 first]
2. [Item] — Why deferred: [Reason]

Action item quality test:

• Is it specific enough that someone could do it RIGHT NOW? ("Add a pre-deploy checklist to the PR template" > "improve deploy process")
• Does it have ONE owner? ("Sarah" > "the team")
• Is it achievable before next retro? If not, scope it down.
• Will we actually know if it worked? What changes visibly?

Step 5: Follow-Up on Previous Actions

If this isn't the first retro, review actions from last time:

PREVIOUS ACTION REVIEW
═══════════════════════
| Action | Owner | Status | Impact |
|--------|-------|--------|--------|
| [Action from last retro] | [Who] | ✅ Done / 🔄 In Progress / ❌ Not Started | [Did it help?] |
| [Action from last retro] | [Who] | [Status] | [Impact] |

Completion rate: [N]% of previous actions completed
Effective rate: [N]% of completed actions had measurable impact

If completion rate < 50%:
⚠️ Action follow-through is low. Consider:
- Are we committing to too many actions? (Reduce to 1 next sprint)
- Are actions too vague? (Make more specific)
- Is there no accountability mechanism? (Review at standup weekly)

Step 6: Retro Summary

RETROSPECTIVE SUMMARY
══════════════════════════════════════
Sprint: [Name/Number]
Format: [Start/Stop/Continue | 4Ls | Mad/Sad/Glad | Sailboat]
Sprint goal met: [Yes / Partially / No]

| Component | Count |
|──────────────────────|──────────────|
| Items discussed | ___ |
| Themes identified | ___ |
| Recurring themes | ___ |
| Action items | ___ (max 2) |
| Previous actions reviewed | ___ |
| Previous actions completed | ___% |
══════════════════════════════════════

Top insight: [The single most important thing learned this sprint]

Actions committed:
1. [Action] — Owner: [Who] — Due: [When]
2. [Action] — Owner: [Who] — Due: [When]

Next retro check: Review these actions at the start of next retro.

Ready for: /sprint (to plan next sprint with these learnings) or /brief --audience team (to communicate changes)

Anti-Patterns — DON'T Do This

• Blame language. "Dave broke the deploy" → "The deploy broke because there's no pre-merge CI check." Always redirect to systems, not individuals.
• Vague actions. "Communicate better" is not an action. "Post a 2-sentence status update in #engineering at 3pm daily" is an action.
• Too many actions. Five actions = zero actions. Commit to 1-2 and actually do them.
• Skipping follow-up. If you don't review last retro's actions, the team learns that retro actions don't matter. Always start by reviewing what happened with previous commitments.
• Only negative. If the retro is only about what went wrong, the team dreads it. Positive themes matter — they tell you what to protect and double down on.
• Retro fatigue. If the team is going through the motions, change the format. That's why this skill offers four formats. Rotate.

Formatting Rules

• Sprint scorecard shows planned vs. actual — honest assessment
• Every frustration/problem includes a root cause analysis, not just the symptom
• Recurring themes are flagged with history across retros
• Action items have: specific action, single owner, due date, and success criteria
• Previous actions are reviewed FIRST before generating new ones
• After presenting themes and actions, pause: "Do these actions feel like the right ones? Will they actually change behavior next sprint?"