Conduct a Retrospective

Facilitate structured retrospective → review recent project exec, ID what worked + what didn't, produce actionable improvements w/ owners + due dates. Transforms raw project data → evidence-backed learnings w/ specific actions, owners, due dates.

Use When

• End of sprint (sprint retrospective)
• End of project phase / milestone
• Post significant incident, failure, or success
• Quarterly review of ongoing project procs
• Before starting similar project (lessons learned review)

In

• Required: Period under review (sprint number, date range, or milestone)
• Optional: Status reports from review period
• Optional: Sprint velocity + completion data
• Optional: Prev retrospective actions (check closure)
• Optional: Team feedback / survey results

Do

Step 1: Gather Retrospective Data

Read available artifacts from review period:

• STATUS-REPORT-*.md files for period
• SPRINT-PLAN.md for planned vs actual
• BACKLOG.md for item flow + cycle times
• Prev RETRO-*.md for open action items

Extract key facts:

• Items planned vs completed
• Velocity trend
• Blockers encountered + resolution time
• Unplanned work entering sprint
• Open action items from prev retros

→ Data summary w/ quantitative metrics (velocity, completion %, blocker count).

If err: No artifacts → base retro on qualitative observations.

Step 2: Structure "What Went Well"

List 3-5 things that worked, w/ evidence:

## What Went Well
| # | Observation | Evidence |
|---|------------|---------|
| 1 | [Specific positive observation] | [Metric, example, or artifact reference] |
| 2 | [Specific positive observation] | [Metric, example, or artifact reference] |
| 3 | [Specific positive observation] | [Metric, example, or artifact reference] |

Focus on practices to continue, not outcomes. "Daily standups kept blockers visible" > "We delivered on time."

→ 3-5 evidence-backed positive observations.

If err: Nothing went well → look harder. Small wins matter. At min, team completed period.

Step 3: Structure "What Needs Improvement"

List 3-5 things needing improvement, w/ evidence:

## What Needs Improvement
| # | Observation | Evidence | Impact |
|---|------------|---------|--------|
| 1 | [Specific issue] | [Metric, example, or incident] | [Effect on delivery] |
| 2 | [Specific issue] | [Metric, example, or incident] | [Effect on delivery] |
| 3 | [Specific issue] | [Metric, example, or incident] | [Effect on delivery] |

Specific + factual. "Estimation was off" = vague. "3 of 5 items exceeded estimates by >50%, adding 8 unplanned days" = actionable.

→ 3-5 evidence-backed improvement areas w/ stated impact.

If err: Team claims everything fine → compare planned vs actual metrics → gaps reveal issues.

Step 4: Generate Improvement Actions

Each improvement area → actionable item:

## Improvement Actions
| ID | Action | Owner | Due Date | Success Criteria | Source |
|----|--------|-------|----------|-----------------|--------|
| A-001 | [Specific action] | [Name] | [Date] | [How to verify success] | Improvement #1 |
| A-002 | [Specific action] | [Name] | [Date] | [How to verify success] | Improvement #2 |
| A-003 | [Specific action] | [Name] | [Date] | [How to verify success] | Improvement #3 |

Each action must be:

• Specific (not "improve estimation" but "add estimation review step to grooming")
• Owned (one person accountable)
• Time-bound (due date w/in next 1-2 sprints)
• Verifiable (success criteria defined)

→ 2-4 improvement actions w/ owners + due dates.

If err: Actions too vague → apply "how would you verify this was done?" test.

Step 5: Review Previous Actions + Write Report

Check prev retrospective actions for closure:

## Previous Action Review
| ID | Action | Owner | Status | Notes |
|----|--------|-------|--------|-------|
| A-prev-001 | [Action from last retro] | [Name] | Closed / Open / Recurring | [Outcome] |
| A-prev-002 | [Action from last retro] | [Name] | Closed / Open / Recurring | [Outcome] |

Flag recurring items (same issue appearing 3+ retros) → escalation or different approach needed.

Write complete retrospective:

# Retrospective: [Sprint N / Phase Name / Date Range]
## Date: [YYYY-MM-DD]
## Document ID: RETRO-[PROJECT]-[YYYY-MM-DD]

### Period Summary
- **Period**: [Sprint N / dates]
- **Planned**: [N items / N points]
- **Completed**: [N items / N points]
- **Velocity**: [N] (previous: [N])
- **Unplanned Work**: [N items]

### What Went Well
[From Step 2]

### What Needs Improvement
[From Step 3]

### Improvement Actions
[From Step 4]

### Previous Action Review
[From Step 5]

---
*Retrospective facilitated by: [Name/Agent]*

Save as RETRO-[YYYY-MM-DD].md.

→ Complete retrospective doc saved w/ actions, evidence, prev action review.

If err: Retro has no improvement actions → not driving change → revisit Step 3.

Check

• Retro file created w/ date-stamped filename
• Period summary includes quantitative metrics
• "What Went Well" has 3-5 evidence-backed items
• "What Needs Improvement" has 3-5 evidence-backed items
• Improvement actions have owners, due dates, success criteria
• Prev retro actions reviewed for closure
• Recurring issues flagged

Traps

• Blame game: Retros review procs + practices, not people. Frame issues systemic, not personal.
• Actions w/o follow-through: Biggest retro failure. Always review prev actions before creating new.
• Too many actions: 2-4 focused > 10 vague. Team can only absorb so many changes.
• No evidence: "We feel estimation bad" = opinion. "3 of 5 items exceeded estimates by 50%" = data. Always attach evidence.
• Skip positives: Only discussing problems demoralizing. Celebrating wins reinforces good practices.

→

• generate-status-report — status reports provide data for retros
• manage-backlog — improvement actions feed back into backlog
• plan-sprint — retro learnings improve sprint planning accuracy
• draft-project-charter — review charter assumptions + risk accuracy
• create-work-breakdown-structure — review estimation accuracy vs. WBS