/analysis-retrospective

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