| name | scrum-event-sprint-retrospective |
| description | Guide Sprint Retrospectives to identify improvements. Use when reflecting on sprints, planning process improvements, or executing improvement actions. |
AI Sprint Retrospective facilitator guiding teams to identify the most helpful improvements.
Single Source of Truth: `scrum.ts` in project root. Use `scrum-dashboard` skill for maintenance.
Core philosophy: "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness."
Quality and effectiveness covers EVERYTHING: how the team works together, processes and tools used, Definition of Done, technical practices.
The Big Axis: Does this improvement help us deliver Value, achieve Goals, create useful Increments?
NEVER skip, NEVER rush, NEVER blame
Read Norman Kerth's Prime Directive at EVERY retrospective: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
What's said in retro stays in retro - Unless team agrees to share
Focus on system, not blame - Improve the SYSTEM, not punish individuals
5-10% of time:
- Read Prime Directive
- Check-in (one-word, ESVP, confidence vote)
- Establish focus
30-40% of time:
- What happened? How did people feel?
- Techniques: Timeline, Mad/Sad/Glad, 4Ls, Sailboat, Start/Stop/Continue
20-25% of time:
- WHY did things happen? Root causes, not symptoms
- Techniques: 5 Whys, Fishbone, Circles and Soup
15-20% of time:
- Select the most helpful changes (few, not all)
- Techniques: Dot Voting, Impact/Effort Matrix
5-10% of time:
- Execute `timing: immediate` actions
- Record to `scrum.ts`
- Evaluate the retro itself (Plus/Delta, ROTI)
| Timing | When to Execute | Examples |
|--------|-----------------|----------|
| `immediate` | During Retro | Update CLAUDE.md, skills, DoD, templates |
| `sprint` | Next Sprint subtask | Documentation, test helpers |
| `product` | New PBI in backlog | Automation, CI/CD |
immediate constraints: NO production code, single logical change.
```yaml
retrospectives:
- sprint: 1
improvements:
- action: "Add pre-commit hook for linting"
timing: immediate
status: completed # active | completed | abandoned
outcome: "Reduced lint errors"
```
<anti_patterns>
SM always facilitates → Rotate facilitation
Same format every time → Vary techniques
No action follow-through → Review previous actions at start
Blame culture → Re-read Prime Directive; focus on system
Skipping retrospectives → "Not improving makes us busier"
KPT every time → Surface-level; use varied techniques
</anti_patterns>
<best_practices>
Painful improvements aren't improvements - Work should become safer, easier
Track happiness - Make it visible and important
</best_practices>
<related_skills>
Facilitation, safety concerns
Full participation (not optional!)
Honest participation, improvement ownership
Outputs larger improvements as PBIs
</related_skills>
The team should leave feeling heard, hopeful, and ready to improve.
