codexkit-scrum-retrospective

Facilitate and document Sprint Retrospectives per Scrum Guide 2020. Choose format by team maturity, structure the session, capture action items, and track improvement across sprints. Use after every sprint. Do not use for individual performance reviews, blame sessions, or annual assessments.

hoavdc/codexkit1 installsMITSynced Aug 22

Works with

Claude CodeCursorCodex CLIGitHub CopilotGemini CLI
---
name: codexkit-scrum-retrospective
description: Facilitate and document Sprint Retrospectives per Scrum Guide 2020. Choose format by team maturity, structure the session, capture action items, and track improvement across sprints. Use after every sprint. Do not use for individual performance reviews, blame sessions, or annual assessments.
license: MIT
---

# Sprint Retrospective Facilitator

## Purpose

Turn sprint reflections into structured improvement actions by choosing the right retrospective format, guiding the session, and producing trackable outcomes.

## When to use

- after every sprint to reflect on process and teamwork
- when team morale or velocity is declining and root causes are unclear
- when previous retro action items keep recurring without resolution
- when onboarding a new Scrum Master who needs facilitation structure

## When not to use

- individual performance evaluation or disciplinary review
- project-level strategic retrospectives (use lessons-learned skill)
- mid-sprint debugging sessions

## Inputs

- sprint number and duration
- sprint goal and whether it was met
- velocity or throughput data (current + last 3 sprints)
- previous retro action items and their completion status
- team size and maturity level (forming / storming / norming / performing)
- any specific incidents or friction points to address

## Procedure

1. **Select format** based on team maturity:
   - Forming (< 3 sprints): Start / Stop / Continue
   - Storming (3–10 sprints): 4Ls — Liked, Learned, Lacked, Longed For
   - Norming (stable team): Sailboat — Wind / Anchors / Rocks / Island
   - Performing (high trust): Lean Coffee, ORID, Timeline Retro
   - Crisis / specific problem: Fishbone + 5 Whys
2. **Set the stage** (10 min): Run ESVP check (Explorer/Shopper/Vacationer/Prisoner), review working agreements, safety check (1–5 scale).
3. **Gather data** (20 min): Build sprint timeline of key events, review velocity trend and defect rate.
4. **Generate insights** (25 min): Dot voting (3 dots per person), affinity clustering, 5 Whys on top-voted issue.
5. **Decide actions** (25 min): Maximum 3 action items. Each: What + Who + Done-by-when + Success criteria. Check carryover from last retro.
6. **Close** (10 min): Team health pulse (1–5 on 3 dimensions), appreciation round, retro-of-the-retro score.

## Output

- retro summary with format used and key data gathered
- action items table: What | Owner | Due Date | Success Criteria | Status
- team health index trend (tracked across sprints)
- carryover escalation if same item recurs 3+ times without resolution

## Definition of done

- maximum 3 action items, each with a named owner and due date
- team health pulse recorded
- previous retro carryover items are reviewed and their status documented
- output is shareable with stakeholders within 24 hours

## Examples

- "Run a retrospective for Sprint 8 with a norming team of 6 — velocity dropped 15% this sprint."
- "Our last 3 retros had the same 'unclear requirements' action item. Help us escalate."
- "Facilitate a Fishbone retro to investigate why the deployment failed last sprint."

## Quality Criteria

- [ ] Feedback is specific and references exact locations in the reviewed material
- [ ] Each critique includes a concrete improvement suggestion
- [ ] Severity is categorized (critical / important / nice-to-have)
- [ ] Positive aspects are acknowledged alongside areas for improvement

## Verification (4C)

| Check | Question |
|-------|----------|
| **Correctness** | Is the feedback technically accurate and properly contextualized? |
| **Completeness** | Were all major sections of the reviewed material addressed? |
| **Context-fit** | Is the review granularity appropriate for the material's maturity level? |
| **Consequence** | If the author implemented all feedback literally, what could go wrong? |

## Edge Cases

- **Material is too early-stage for detailed review** — Provide structural feedback only. Note that content review is deferred until it matures.
- **Reviewer lacks domain expertise** — Focus on structure, clarity, and consistency. Flag domain-specific claims as 'Needs SME verification'.
- **Author is defensive or resistant to feedback** — Lead with what works well. Frame changes as questions rather than mandates.

## Changelog

- v1.0.0 — Initial release

More Project Management skills

← All Project Management skills

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY