| name | codexkit-scrum-retrospective |
| description | Facilitate and document Sprint Retrospectives per Scrum Guide 2020. Choose format by team maturity, structure the session, capture action items, and track improvement across sprints. Use after every sprint. Do not use for individual performance reviews, blame sessions, or annual assessments. |
| version | 1.0.0 |
| category | review |
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
- 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
- Set the stage (10 min): Run ESVP check (Explorer/Shopper/Vacationer/Prisoner), review working agreements, safety check (1–5 scale).
- Gather data (20 min): Build sprint timeline of key events, review velocity trend and defect rate.
- Generate insights (25 min): Dot voting (3 dots per person), affinity clustering, 5 Whys on top-voted issue.
- Decide actions (25 min): Maximum 3 action items. Each: What + Who + Done-by-when + Success criteria. Check carryover from last retro.
- 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
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
