# Sprint Retrospective Formats

## Start/Stop/Continue

**Best for:** Teams new to retrospectives, quick format
**Duration:** 45-60 minutes

### Structure
Create three columns:
- **Start:** What should we begin doing?
- **Stop:** What should we stop doing?
- **Continue:** What's working well that we should keep doing?

### Process
1. Team silently adds items to each column (10 min)
2. Group similar items (5 min)
3. Discuss each category, vote on top items (20 min)
4. Select 2-3 actions (10 min)

### Example Output
**Start:**
- Pairing on complex stories
- Code reviews within 4 hours

**Stop:**
- Taking on work mid-sprint
- Skipping acceptance criteria

**Continue:**
- Daily standups at 9:30am
- Demo prep on Thursday
---

## Glad/Sad/Mad

**Best for:** Emotional check-in, team morale assessment
**Duration:** 60-75 minutes

### Structure
Create three areas:
- **Glad:** What made you happy this sprint?
- **Sad:** What disappointed you?
- **Mad:** What frustrated you?

### Process
1. Silent brainstorming (10 min)
2. Share items, one person at a time (15 min)
3. Group themes (5 min)
4. Discuss top items from each category (20 min)
5. Identify action items (10 min)

### Example Output
**Glad:**
- Shipped feature X on time
- Great collaboration with design team
- New deployment process worked well

**Sad:**
- Lost time to production bugs
- Didn't finish all committed work
- Documentation fell behind

**Mad:**
- Environment was down 2 days
- Requirements changed mid-sprint
- Still waiting on API key from vendor

### Facilitation Tips
- Acknowledge emotions, don't dismiss
- Focus on what we can control
- Convert frustrations into actions

---

## 4Ls (Liked, Learned, Lacked, Longed For)

**Best for:** Deeper reflection, learning focus
**Duration:** 60-90 minutes

### Structure
- **Liked:** What went well? What did we enjoy?
- **Learned:** What new insights did we gain?
- **Lacked:** What was missing? What did we need?
- **Longed For:** What do we wish we had?

### Process
1. Individual reflection (10 min)
2. Round-robin sharing (20 min)
3. Group similar items (10 min)
4. Deep dive on top items (20 min)
5. Action planning (15 min)

### Example Output
**Liked:**
- Pair programming sessions
- Clear acceptance criteria
- Product Owner availability

**Learned:**
- New testing framework capabilities
- How to better estimate stories
- Importance of architectural review

**Lacked:**
- Automated deployment
- Clear API documentation
- Sufficient testing time

**Longed For:**
- Better development environments
- More design time upfront
- Dedicated QA support

---

## Sailboat

**Best for:** Visual teams, identifying headwinds and tailwinds
**Duration:** 60-90 minutes

### Structure
Draw a sailboat with:
- **Wind (propellers):** What's helping us go faster?
- **Anchors:** What's slowing us down?
- **Rocks (hazards):** What risks are ahead?
- **Island (goal):** Where are we headed?

### Process
1. Explain metaphor (5 min)
2. Team adds sticky notes to each area (15 min)
3. Group and discuss each area (30 min)
4. Prioritize anchors to remove (10 min)
5. Create action plan (15 min)

### Example Output
**Wind:**
- Strong team collaboration
- Clear product vision
- Good tooling

**Anchors:**
- Slow CI/CD pipeline
- Too many meetings
- Technical debt

**Rocks:**
- Upcoming dependency on Team B
- Key person on vacation next sprint
- Infrastructure migration

**Island:**
- Launch v2.0 by end of quarter
- Improve system stability
- Reduce production bugs by 50%

---

## Timeline

**Best for:** Detailed sprint review, identifying patterns
**Duration:** 75-90 minutes

### Structure
Create a timeline of the sprint on a whiteboard:
- Days of the sprint across the top
- Events, milestones, feelings plotted on timeline

### Process
1. Draw sprint timeline (5 min)
2. Team adds events chronologically (15 min)
3. Add emotion indicators (happy/sad/stressed) (10 min)
4. Identify patterns and themes (20 min)
5. Discuss high/low points (20 min)
6. Extract learnings and actions (15 min)

### Example Timeline
```
Day 1: Sprint planning, feeling optimistic 😊
Day 3: Production bug discovered, stressed 😰
Day 5: Bug fixed, relieved 😌
Day 7: Design feedback changed scope, frustrated 😠
Day 9: Great pairing session on new feature 😊
Day 10: Demo went really well! 🎉
```

### Facilitation Tips
- Focus on objective events first, emotions second
- Look for correlations between events and feelings
- Identify early warning signs
- Celebrate wins

---

## Starfish

**Best for:** More granular feedback than Start/Stop/Continue
**Duration:** 60-90 minutes

### Structure
Five categories:
- **Keep Doing:** What's working, don't change
- **Less Of:** What should we reduce?
- **More Of:** What should we increase?
- **Stop Doing:** What should we eliminate?
- **Start Doing:** What new practices should we try?

### Process
1. Explain each category (5 min)
2. Silent brainstorming (15 min)
3. Share and group items (15 min)
4. Discuss each category (25 min)
5. Vote on top actions (10 min)
6. Create action plan (15 min)

### Example Output
**Keep Doing:**
- Pairing on complex stories
- Demo every Friday

**Less Of:**
- Context switching
- Unplanned work

**More Of:**
- Automated testing
- Design upfront

**Stop Doing:**
- Skipping code reviews
- Working weekends

**Start Doing:**
- Mob programming for knowledge sharing
- Weekly architecture discussions

---

## Speed Dating

**Best for:** Large teams, fresh perspectives
**Duration:** 60 minutes

### Structure
- Pair up team members who don't usually work together
- Rotate pairs every 10 minutes
- Discuss sprint from different perspectives

### Process
1. Create pairs (2 min)
2. Round 1: "What went well?" (10 min)
3. Rotate pairs (2 min)
4. Round 2: "What could improve?" (10 min)
5. Rotate pairs (2 min)
6. Round 3: "What should we try?" (10 min)
7. Full group synthesis (15 min)
8. Action planning (10 min)

### Facilitation Tips
- Ensure quiet voices are heard
- Mix up pairs intentionally
- Capture themes as they emerge
- Focus on shared themes in synthesis

---

## Three Little Pigs

**Best for:** Architecture and technical decisions
**Duration:** 60-75 minutes

### Structure
Based on the story:
- **Straw House:** What's fragile? What will blow down?
- **Stick House:** What's okay but could be better?
- **Brick House:** What's solid and will last?

### Process
1. Explain metaphor (5 min)
2. Team identifies items for each house (15 min)
3. Group and discuss (20 min)
4. Prioritize straw house items to fix (10 min)
5. Create action plan (15 min)

### Example Output
**Straw House (fragile):**
- Manual deployment process
- No automated tests for API
- Undocumented code

**Stick House (needs improvement):**
- Test coverage at 60%
- Some documentation exists
- Partially automated builds

**Brick House (solid):**
- Strong CI/CD for frontend
- Well-tested core modules
- Clear architecture docs

---

## Facilitation Best Practices

### Before Retrospective
- Review previous action items
- Gather sprint metrics
- Choose format based on team needs
- Prepare collaboration space

### During Retrospective
- **Set the stage:** Create safe environment
- **Prime directive:** "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."
- **Timebox discussions:** Keep energy high
- **Focus on actions:** Not just talk
- **Limit action items:** 1-3 max for next sprint
- **Get specific:** Vague actions don't happen

### After Retrospective
- Document immediately in Confluence
- Create Jira tickets for actions
- Assign owners and due dates
- Track completion
- Start next retro by reviewing these

### Red Flags
- Same issues every retro → Need deeper intervention
- No action items → Team not engaged
- Blame game → Not safe environment
- No follow-through → Actions not valued
- Facilitator talks more than team → Not facilitating

### Rotation Strategy
- Vary formats every 2-3 sprints
- Let team choose occasionally
- Match format to team mood
- Try new format when stuck
