# Retrospective To Action

> Retrospective to Action

- Skill: `sethdford/retrospective-to-action` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/retrospective-to-action`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/retrospective-to-action/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/retrospective-to-action

---

# Retrospective to Action

Runs a structured retro that produces actionable items assigned to specific roles.

## Domain Context

Retrospectives are where teams reflect on how they work and commit to changes. But many retros become venting sessions with no follow-up. The difference is structure: **retrospective-to-action** ensures that:

1. Observations are categorized (what went well, what didn't, what confused us)
2. Root causes are identified
3. Improvements are concrete and assigned
4. Improvements are prioritized and tracked

**ISO/IEC 12207 Reference:**

- 5.3.11 Disposal (lessons learned, process improvements)

## Instructions

### Step 1: Frame the Retro

- **Input**: Sprint context (dates, team size, key events)
- **Ask**: What were the sprint goals?
- **Ask**: Did we hit them? (yes/partial/no)
- **Ask**: What external events impacted the sprint? (incidents, stakeholder changes, dependency delays)

Output: Retro framing

### Step 2: Observations (What Happened)

Ask the team to capture observations in three categories:

**What Went Well?**

- Examples: "Code review process was smooth", "Feature shipped on time", "Team collaboration was great"
- Ask the team: What should we keep doing?

**What Didn't Go Well?**

- Examples: "Testing took longer than expected", "Communication with PM was unclear", "We shipped a bug to production"
- Ask the team: What should we change?

**What Confused Us?**

- Examples: "Requirements changed mid-sprint", "We weren't sure about the design until mid-development", "Monitoring didn't catch the issue"
- Ask the team: What would make this clearer next time?

Output: Observation lists from all team members

### Step 3: Root Cause Analysis

For each "didn't go well" observation:

- **Ask**: Why did this happen? (ask at least once)
- **Ask**: What could we have done differently?
- **Ask**: Is this a systemic issue or a one-time event?

Output: Root causes and potential improvements

### Step 4: Improvement Ideas

For each root cause:

- **Ask**: What's an improvement that would prevent this next sprint?
- **Ask**: Who would own this? (engineer, QA, PM, tech lead, designer)
- **Ask**: How much effort? (quick win, sprint work, epic work)

Output: Improvement ideas with owners and effort estimates

### Step 5: Prioritize Improvements

- **Quick wins** (< 1 hour) — Do this immediately
- **Sprint work** (1-5 days) — Add to next sprint backlog
- **Epic work** (> 5 days) — Plan for future sprint

- **High impact** — Affects multiple people, prevents recurrence of major issue
- **Medium impact** — Affects some people, improves efficiency
- **Low impact** — Nice to have, low urgency

Output: Prioritized improvement list

### Step 6: Assign Owners

For each improvement:

- **Ask**: Who should own this?
- **Ask**: Can they commit to doing it?

Output: Assignments

### Step 7: Consolidate Retro Notes
```

Retrospective: Sprint [N]
Date: [Date]
Team: [Members]

Sprint Goals: [Goals]
Goal Achievement: [Yes / Partial / No]
Key Events: [Incidents, blockers, changes]

What Went Well:
• [Observation] - Team sentiment: [positive]
• [Observation] - Team sentiment: [positive]
• [Observation] - Team sentiment: [positive]

What Didn't Go Well:
• [Observation] - Root cause: [cause] - Improvement: [idea]
• [Observation] - Root cause: [cause] - Improvement: [idea]
• [Observation] - Root cause: [cause] - Improvement: [idea]

What Confused Us:
• [Observation] - Clarity improvement: [idea]
• [Observation] - Clarity improvement: [idea]

Improvements (Prioritized):
Quick Wins (< 1 hour):
[ ] [Improvement] - Owner: [name] - Effort: [estimate]
[ ] [Improvement] - Owner: [name] - Effort: [estimate]

Sprint Work (1-5 days):
[ ] [Improvement] - Owner: [name] - Effort: [estimate]
[ ] [Improvement] - Owner: [name] - Effort: [estimate]

Epic Work (> 5 days):
[ ] [Improvement] - Owner: [name] - Effort: [estimate]

Backlog Items Created:
[ ] [Issue ID] - [Title] - [Owner] - [Sprint]
[ ] [Issue ID] - [Title] - [Owner] - [Sprint]
[ ] [Issue ID] - [Title] - [Owner] - [Sprint]

Follow-Up:
Next retro date: [Date]
Review improvement status: [Yes / No]

```

### Step 8: Close the Loop

- **Immediately** — Assign quick wins; expect completion in next 1-2 days
- **Next Sprint** — Prioritize sprint work improvements into backlog
- **Future** — Track epic work improvements; plan for dedicated sprint

## Anti-Patterns

1. **Retros without follow-up**
   - Mistake: "We did retro, identified improvements, but never tracked them"
   - Correct: Every improvement becomes a backlog item with an owner
   - Fix: PM is responsible for creating and tracking improvement backlog items

2. **Retros that blame individuals**
   - Mistake: "Engineer shipped a bug, so they should write better code"
   - Correct: Bugs are systemic failures (inadequate testing, unclear requirements, design issues)
   - Fix: Focus on systemic improvements, not individual blame

3. **Treating all observations as equally important**
   - Mistake: "All 15 observations get equal discussion time"
   - Correct: Prioritize by impact and effort
   - Fix: Time-box the retro (60 min for week sprint); prioritize top 5 improvements

4. **Improvements with no owners**
   - Mistake: "We should improve testing" (but no one owns it)
   - Correct: Every improvement has a specific owner who commits to it
   - Fix: In retro, ask: "Who owns this? Can you commit to next sprint?"

5. **Not reviewing improvement status in the next retro**
   - Mistake: "We created improvement items, but never checked if they happened"
   - Correct: Start next retro by reviewing previous sprint's improvements
   - Fix: Retro agenda always includes: "Review last sprint's improvement items"

6. **Retros that don't inform process changes**
   - Mistake: "We retro, but DoR/DoD never change based on learnings"
   - Correct: Retros should evolve team practices
   - Fix: Question: "Should this observation change our DoR or DoD?"

## Further Reading

- **Agile Retrospectives** — Derby, E. & Larsen, D., "Agile Retrospectives: Making Good Teams Great" (Pragmatic Bookshelf)
- **Blameless Postmortems** — Edmonson, A., "The Fearless Organization" (Wiley)
- **Continuous Improvement** — Liker, J., "The Toyota Way" (McGraw-Hill)