Sprint Retrospective Facilitator

Purpose

Turn sprint reflections into structured improvement actions by choosing the right retrospective format, guiding the session, and producing trackable outcomes.

When to use

• after every sprint to reflect on process and teamwork
• when team morale or velocity is declining and root causes are unclear
• when previous retro action items keep recurring without resolution
• when onboarding a new Scrum Master who needs facilitation structure

When not to use

• individual performance evaluation or disciplinary review
• project-level strategic retrospectives (use lessons-learned skill)
• mid-sprint debugging sessions

Inputs

• sprint number and duration
• sprint goal and whether it was met
• velocity or throughput data (current + last 3 sprints)
• previous retro action items and their completion status
• team size and maturity level (forming / storming / norming / performing)
• any specific incidents or friction points to address

Procedure

1. Select format based on team maturity:
   • Forming (< 3 sprints): Start / Stop / Continue
   • Storming (3–10 sprints): 4Ls — Liked, Learned, Lacked, Longed For
   • Norming (stable team): Sailboat — Wind / Anchors / Rocks / Island
   • Performing (high trust): Lean Coffee, ORID, Timeline Retro
   • Crisis / specific problem: Fishbone + 5 Whys
2. Set the stage (10 min): Run ESVP check (Explorer/Shopper/Vacationer/Prisoner), review working agreements, safety check (1–5 scale).
3. Gather data (20 min): Build sprint timeline of key events, review velocity trend and defect rate.
4. Generate insights (25 min): Dot voting (3 dots per person), affinity clustering, 5 Whys on top-voted issue.
5. Decide actions (25 min): Maximum 3 action items. Each: What + Who + Done-by-when + Success criteria. Check carryover from last retro.
6. Close (10 min): Team health pulse (1–5 on 3 dimensions), appreciation round, retro-of-the-retro score.

Output

• retro summary with format used and key data gathered
• action items table: What | Owner | Due Date | Success Criteria | Status
• team health index trend (tracked across sprints)
• carryover escalation if same item recurs 3+ times without resolution

Definition of done

• maximum 3 action items, each with a named owner and due date
• team health pulse recorded
• previous retro carryover items are reviewed and their status documented
• output is shareable with stakeholders within 24 hours

Examples

• "Run a retrospective for Sprint 8 with a norming team of 6 — velocity dropped 15% this sprint."
• "Our last 3 retros had the same 'unclear requirements' action item. Help us escalate."
• "Facilitate a Fishbone retro to investigate why the deployment failed last sprint."

Quality Criteria

• Feedback is specific and references exact locations in the reviewed material
• Each critique includes a concrete improvement suggestion
• Severity is categorized (critical / important / nice-to-have)
• Positive aspects are acknowledged alongside areas for improvement

Verification (4C)

Check	Question
Correctness	Is the feedback technically accurate and properly contextualized?
Completeness	Were all major sections of the reviewed material addressed?
Context-fit	Is the review granularity appropriate for the material's maturity level?
Consequence	If the author implemented all feedback literally, what could go wrong?

Edge Cases

• Material is too early-stage for detailed review — Provide structural feedback only. Note that content review is deferred until it matures.
• Reviewer lacks domain expertise — Focus on structure, clarity, and consistency. Flag domain-specific claims as 'Needs SME verification'.
• Author is defensive or resistant to feedback — Lead with what works well. Frame changes as questions rather than mandates.

Changelog

• v1.0.0 — Initial release