---
name: agileflow-retro-facilitator
description: Structures retrospective discussions using Start/Stop/Continue format with action items and accountability. Loads during retrospective conversations or sprint reviews.
allowed-tools: Read, Write, Edit
---

# AgileFlow Retro Facilitator

## Purpose

This skill facilitates sprint retrospectives by structuring feedback, identifying actionable improvements, and tracking action items across sprints.

## When This Skill Activates

Load this skill when:
- User mentions "retrospective", "retro", "sprint review"
- Discussing what went well/poorly in a sprint
- User says "let's reflect on..." or "how can we improve..."
- Gathering team feedback
- User mentions "lessons learned", "process improvements"

## Retro Format (Start/Stop/Continue)

```markdown
# Sprint [Number] Retrospective

**Date**: YYYY-MM-DD
**Facilitator**: [Name]
**Attendees**: [Team members present]
**Sprint Duration**: [Start] - [End]

## Sprint Metrics

- **Committed**: X story points
- **Completed**: Y story points
- **Velocity**: Z%
- **Stories Done**: A / B
- **Bugs Found**: C
- **Blockers**: D

## What Went Well ✅

- [Positive 1: Specific thing that worked]
- [Positive 2: Team success]
- [Positive 3: Process improvement]

## What Didn't Go Well ❌

- [Challenge 1: Specific problem]
- [Challenge 2: Blocker or delay]
- [Challenge 3: Process issue]

## Start (New Practices) 🟢

- **[Practice 1]**
  - Why: [Reasoning]
  - Owner: [Who will drive this]
  - Success metric: [How we'll measure]

## Stop (Remove Practices) 🔴

- **[Practice 1]**
  - Why it's not working: [Reasoning]
  - Alternative: [What we'll do instead]

## Continue (Keep Doing) 🟡

- **[Practice 1]**
  - Why it's working: [Reasoning]
  - How to maintain: [Keep it going]

## Action Items

- [ ] **[Action 1]** - @Owner - Due: [Date]
  - Success criteria: [How we know it's done]

- [ ] **[Action 2]** - @Owner - Due: [Date]
  - Success criteria: [How we know it's done]

## Previous Action Items Review

- [✅] **[Completed Action]** - Implemented, improved X by Y%
- [🔄] **[In Progress Action]** - Still working on it, 60% done
- [❌] **[Not Done Action]** - Blocked by Z, rolling to next sprint

## Key Insights

1. [Insight 1: Pattern or learning]
2. [Insight 2: Team dynamic observation]
3. [Insight 3: Process discovery]

## Next Retrospective

**Date**: [Next retro date]
**Focus Areas**: [Specific topics to revisit]
```

## Workflow

1. **Set the Stage**:
   - Review sprint metrics (velocity, completion rate)
   - Check previous action items

2. **Gather Feedback**:
   - What went well?
   - What didn't go well?
   - What should we start doing?
   - What should we stop doing?
   - What should we continue doing?

3. **Identify Patterns**:
   - Group similar feedback
   - Find root causes
   - Spot recurring themes

4. **Create Action Items**:
   - Specific, actionable steps
   - Assign owners
   - Set due dates
   - Define success criteria

5. **Document and Share**:
   - Save in `docs/08-project/retros/`
   - Share with team
   - Add action items to backlog if needed

## Retro Formats (Choose Based on Context)

### 1. Start/Stop/Continue (Standard)
Best for: Regular sprint retros

### 2. Glad/Sad/Mad
Best for: Emotional topics, team dynamics

```markdown
## Glad 😊
- [Things that made us happy]

## Sad 😔
- [Things that disappointed us]

## Mad 😡
- [Things that frustrated us]
```

### 3. 4Ls (Liked, Learned, Lacked, Longed For)
Best for: Learning-focused retros

```markdown
## Liked 👍
- [What we enjoyed]

## Learned 💡
- [New knowledge or skills]

## Lacked ⚠️
- [What was missing]

## Longed For 🌟
- [What we wish we had]
```

### 4. Sailboat (Wind, Anchor, Rocks, Island)
Best for: Visual teams, long-term goals

```markdown
## Wind ⛵ (What pushes us forward)
- [Helpful forces]

## Anchor ⚓ (What slows us down)
- [Obstacles]

## Rocks 🪨 (What could sink us)
- [Risks]

## Island 🏝️ (Our goal)
- [Where we want to be]
```

## Good vs Bad Feedback

### Good (Specific, Actionable):
```markdown
✅ "Daily standups ran long (20+ min) because we discussed implementation details.
    Consider moving technical discussions to separate sessions."

✅ "Code reviews were faster this sprint (avg 4 hours vs 24 hours last sprint)
    thanks to smaller PR sizes. Let's keep PRs under 300 lines."

✅ "Unclear acceptance criteria on STORY-042 led to 3 days of rework.
    We should refine stories more thoroughly during planning."
```

### Bad (Vague, Blame-Oriented):
```markdown
❌ "Meetings were bad"
❌ "Bob didn't do his job"
❌ "Everything was terrible"
❌ "Process is broken"
```

## Action Item Quality

### SMART Action Items:
- **S**pecific: Clear what needs to be done
- **M**easurable: Can verify it's complete
- **A**ssignable: Has an owner
- **R**elevant: Addresses the issue
- **T**ime-bound: Has a deadline

### Example:
```markdown
✅ Good:
- [ ] **Create PR size guideline** - @TechLead - Due: Before next sprint
  - Success: Document written, shared with team, added to CLAUDE.md
  - Metric: 80% of PRs under 300 lines

❌ Bad:
- [ ] Fix code reviews
```

## Metrics to Track

### Sprint Health:
- Velocity trend (increasing, stable, decreasing?)
- Commitment accuracy (completed vs committed)
- Bug count (increasing, decreasing?)
- Blocker frequency

### Team Health:
- Meeting effectiveness
- Communication quality
- Collaboration level
- Work-life balance

### Process Health:
- Cycle time (story start to done)
- Code review turnaround
- Deployment frequency
- Incident count

## Common Themes to Watch For

### Positive Patterns:
- 🟢 Consistent velocity
- 🟢 Low bug count
- 🟢 Fast code reviews
- 🟢 Clear requirements
- 🟢 Good collaboration

### Warning Signs:
- 🔴 Declining velocity
- 🔴 Recurring blockers
- 🔴 Communication issues
- 🔴 Scope creep
- 🔴 Burnout indicators

## Integration with Other Skills

- **agileflow-sprint-planner**: Retro insights inform next sprint planning
- **agileflow-tech-debt**: Identifies tech debt to address
- **agileflow-story-writer**: Improves story writing process

## Facilitator Tips

### Do:
- ✅ Create safe space for honest feedback
- ✅ Focus on process, not people
- ✅ Time-box discussions (5-10 min per topic)
- ✅ Ensure everyone participates
- ✅ End on positive note
- ✅ Follow up on action items

### Don't:
- ❌ Blame individuals
- ❌ Let discussions run too long
- ❌ Skip retros ("too busy")
- ❌ Create action items without owners
- ❌ Ignore previous action items

## Remote Retro Adaptations

For distributed teams:
- Use anonymous feedback tools (Retrium, Metro Retro)
- Give time for async reflection before meeting
- Use polls/voting for prioritization
- Record session for absent team members
- Use collaborative docs for brainstorming

## Frequency Guidelines

- **Every sprint**: Standard retros (60-90 min)
- **Major milestones**: Extended retros (2-3 hours)
- **Quarterly**: Big-picture retros (process, tools, culture)
- **Post-incident**: Blameless postmortems (as needed)

## Notes

- Retros are for the team, not management reporting
- Psychological safety is critical for honest feedback
- Action items should be small and achievable
- Track action item completion rate (target: >80%)
- Vary retro format to keep it fresh
- Celebrate wins, don't just focus on problems