| 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
- 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).
- Review the project against plan — compare actual timeline, scope, and effort to what was planned; note the gaps.
- Identify what went well — capture at least two things that worked and should be repeated; these are as important as problems.
- Identify root causes of issues — for each problem, apply 5-whys to find the actual cause rather than the symptom.
- Capture reusable learning — use
references/learning_capture.md to decide which learnings belong in: templates, reference docs, checklists, or team norms.
- 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
