sprint-retro

What this skill does

# Sprint Retro

Review the sprint outcome and capture lessons for next time.

## When to Use

- "How did the sprint go?"
- "Let's do a retro"
- "What did we miss?"
- End of sprint or after the driving deadline event
- When something went wrong and you want to capture the lesson

## Arguments

`$ARGUMENTS` can be:
- Empty — review the most recent sprint plan
- A path to a specific plan file

## Workflow

### Phase 1: Gather Evidence

1. **Read the sprint plan** — what was planned, who was assigned what
2. **Read the dashboard** — `docs/features/DASHBOARD.md` — what actually shipped
3. **Check git history** — `git log --oneline --since="[sprint start]"` — what actually landed
4. **Check PR history** — `gh pr list --state all --limit 30` — what was opened, merged, closed

### Phase 2: Planned vs. Actual

Build a comparison table:

```markdown
| Feature | Planned | Actual | Notes |
|---------|---------|--------|-------|
| `feature-a` | Deadline-Critical | Shipped | On track |
| `feature-b` | This Sprint | In Progress | Took longer than expected — effort was Medium, needed Large |
| `feature-c` | This Sprint | Not Started | Blocked by AIDP cluster access |
| `feature-d` | Not Planned | Shipped | Emerged mid-sprint as a dependency |
```

### Phase 3: Identify Patterns

Look for recurring themes:

**Estimation accuracy:**
- Were effort estimates (Small/Medium/Large) accurate?
- Which items took longer than expected? Why?
- Were any items easier than expected?

**Blocking patterns:**
- What blocked progress? (external teams, infrastructure, unclear specs, missing context)
- Could the blocks have been identified earlier?
- Did the dependency graph hold up, or were there surprise dependencies?

**Spec quality:**
- Did developers have to ask questions that should have been in the spec?
- Were any specs missing critical information?
- Did the spec audit (`/sprint-audit-specs`) catch the gaps?

**Assignment quality:**
- Were tasks assigned to the right people?
- Did junior devs get stuck? On what?
- Were senior devs bottlenecked on too many critical-path items?

### Phase 4: Capture Lessons

Format lessons as actionable rules:

```markdown
## Lessons Learned

### What Worked
- [Specific thing that worked well and WHY]
- [Pattern to repeat next sprint]

### What Didn't Work
- [Specific problem and root cause]
- [What we'd do differently]

### Process Improvements
- [Concrete change to make next sprint]
- [E.g., "Add realistic data ranges to all data-generation specs"]
- [E.g., "Verify PR status with `gh pr view` before planning around it"]

### Estimation Calibration
- [Feature X was estimated Small, took Medium — reason: ...]
- [Adjust future estimates for similar work]
```

### Phase 5: Update Plugin Memory

If lessons are broadly applicable (not project-specific), suggest adding them to the sprint-planner plugin itself:
- New checklist items for `/sprint-audit-specs`
- New anti-patterns for `/sprint-triage`
- New rules for `/sprint-plan`

Present these as suggestions — don't auto-modify the plugin.

## Output

Present the retro summary and ask:
- "Anything I missed?"
- "Should we capture any of these lessons in the plugin for next time?"
- "Ready to start planning the next sprint?"

## Integration Notes

Works with:
- `/sprint-plan` — lessons feed into the next sprint's planning
- `/sprint-audit-specs` — retro findings improve the audit checklist
- feature-workflow plugin — reads DASHBOARD.md for shipped status