sprint-retro-facilitator

name: sprint-retro-facilitatordescription: "Run a sprint retrospective that produces real change — themes from what actually happened, honest start/stop/continue, and owned action items, not a vent session. Use when asked to facilitate a retro, run a sprint retrospective, prep retro themes, or turn our sprint into a retro. Produces the data-grounded themes (from done/WIP/blocked work and any flow metrics), a start/stop/continue, 2–4 owned action items with checks, and a follow-up on last retro's actions so retros stop repeating themselves."

Sprint Retro Facilitator

Retros fail two ways: they become a feelings-dump with no actions, or they generate actions no one owns and nothing changes — so next sprint has the same complaints. This grounds the retro in what actually happened (the tickets, the blockers, the metrics), pulls themes from evidence rather than the loudest voice, and produces a small number of owned actions — then holds last retro's actions accountable so the loop actually closes.

What This Skill Produces

• Evidence-grounded themes — patterns drawn from the sprint's done/WIP/blocked work and flow signals, not vibes
• Start / Stop / Continue — concrete, tied to the themes
• 2–4 action items — each with an owner and a "how we'll know it worked" check (fewer, real ones beat a long list)
• Last retro's follow-up — did the previous actions happen, and did they help?

Required Inputs

Ask for these if not provided:

• The sprint data — completed vs planned, tickets that were blocked/carried over, any incidents
• Flow signals (optional) — cycle time, throughput, WIP aging if you track them
• Team sentiment — anything the team already raised (or run it as prompts to gather)
• Last retro's actions — so we can check them (a retro that ignores its own history repeats it)

Framework: A Retro That Changes Something

1. Start from evidence. Themes come from the actual work — carried-over tickets, recurring blockers, a spike in cycle time — so the discussion isn't just who's loudest.
2. Separate systemic from one-off. A blocker that hit three sprints running is a process theme; a freak incident isn't.
3. Few actions, owned. 2–4 max, each with a name and a success check. A retro with 9 actions changes nothing.
4. Close the last loop first. Review previous actions before generating new ones — accountability is what makes retros work.
5. Blameless. Findings are about the system, not people; "the deploy process let a bad config through," not "X broke prod."

Output Format

Retro — Sprint [n]

Since last retro: [previous actions → happened? helped?]

Themes (from the data)

• [theme] — evidence: [tickets/metric]. Systemic or one-off?

Start / Stop / Continue

• Start: … · Stop: … · Continue: …

Actions (owned)

Quality Checks

• Themes cite actual sprint evidence (tickets/metrics), not just opinions
• Systemic patterns are distinguished from one-offs
• Actions are 2–4, each with a named owner and a success check
• Last retro's actions are reviewed before new ones are set
• Framing is blameless — system and process, not individuals

Anti-Patterns

• A vent session with no actions — cathartic, useless.
• Nine action items with no owners — nothing changes.
• Ignoring last retro — guarantees the same issues recur.
• Blame — turns the retro into something people stop being honest in.
• Themes from the loudest voice instead of the data.

Example Trigger Phrases

• "Facilitate our sprint retro from these tickets and metrics."
• "Run a retrospective — here's what got done and what got blocked."
• "Prep retro themes and a start/stop/continue for sprint 14."
• "Help me run a retro that actually leads to change."