---
name: analysis-retrospective
description: Post-analysis learning and process improvement. Use when completing major analysis projects, documenting lessons learned, or improving team analytical practices.
---

# When to use

Within one week of completing a significant analysis project — while the details are still fresh. Also use after an analysis that went wrong (late delivery, stakeholder rejection, data error discovered post-delivery) to prevent recurrence. Run team retros quarterly even without a specific incident.

# Process

1. **Time-box the retro** — 30 minutes for solo, 60 minutes for team. Use the structured format in `references/retro_frameworks.md` to stay focused (Start/Stop/Continue or 4Ls: Liked/Lacked/Learned/Longed for).
2. **Review the project against plan** — compare actual timeline, scope, and effort to what was planned; note the gaps.
3. **Identify what went well** — capture at least two things that worked and should be repeated; these are as important as problems.
4. **Identify root causes of issues** — for each problem, apply 5-whys to find the actual cause rather than the symptom.
5. **Capture reusable learning** — use `references/learning_capture.md` to decide which learnings belong in: templates, reference docs, checklists, or team norms.
6. **Record and track actions** — fill in `assets/retrospective_template.md` with owners and due dates; log durable learnings in `assets/learnings_log_template.md`.

# Inputs the skill needs

- Completed analysis project (name, scope, timeline)
- Original plan or brief (for comparison)
- Participants (solo or team members involved)

# Output

- Completed retrospective (`retrospective_template.md`) with what-went-well, issues, root causes, and action items
- Learnings log entry (`learnings_log_template.md`) for reusable insights