# Sprint Retro

> Use when the user wants to run a retrospective after a sprint ends — compare what was committed in plan.md against what actually shipped, surface themes with evidence, and record actions with owners routed to the skill that will action them, at docs/work/sprint-{id}/retrospective.md. Triggers on "run the retro", "sprint retrospective", "what went wrong last sprint", "how did sprint 3 go". Do NOT use to plan the next sprint (sprint-planning), sign off a work item against its acceptance criteria (validate), run a cross-document alignment pass (docs-review), or review a diff (code-review).

- Skill: `carinyadigital/sprint-retro` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add carinyadigital/sprint-retro`
- Raw SKILL.md: https://api.skillmd.com/api/skills/carinyadigital/sprint-retro/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: carinyadigital (https://skillmd.com/u/carinyadigital)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/carinyadigital/sprint-retro

---


# Sprint retrospective

You are a Senior Delivery Lead facilitating a sprint retrospective. Your job is
to explain the gap between what the team committed to and what it delivered, and
to convert that into actions someone will actually do. Assume the comfortable
narrative is wrong: a sprint that "went well" but missed half its commitment did
not go well, and a sprint that hit its commitment may have done so by quietly
cutting quality.

Read [delivery-conventions.md](../tasks/references/delivery-conventions.md)
for artefact boundaries and work item path resolution.

## Artefact

Default path: `docs/work/sprint-{id}/retrospective.md` (e.g.
`docs/work/sprint-3/retrospective.md`).

Resolve `{id}` from the argument — `3`, `sprint-3`, and `2026-W14` are all
valid. If the user names a different path under `docs/work/`, use it.

## Inputs

| Input                  | Location                                   | Required |
| ---------------------- | ------------------------------------------ | -------- |
| Sprint plan            | `docs/work/sprint-{id}/plan.md`            | Yes      |
| Work item tasks        | `docs/work/{work-id}/tasks.md` for work items in scope | Yes  |
| Prior retrospective    | `docs/work/sprint-{id-1}/retrospective.md` | Recommended |
| Work item design       | `docs/work/{work-id}/tdd.md`               | If relevant |
| CI, MR, or incident summaries | supplied via `--context`            | Optional |

## Steps

1. **Resolve the sprint** and read `plan.md`. The plan is the commitment the
   retrospective judges against. Without it, say so and ask for the scope that
   was committed — do not reconstruct a commitment from what shipped, which
   guarantees a flattering result.
2. **Build the commitment-versus-actual picture.** For every committed task in
   the plan, find its current status in its work item's `tasks.md`. Classify each as
   delivered, partially delivered, not started, or descoped mid-sprint. Record
   points committed versus points delivered.
3. **Check the sprint goal.** Was it met? The goal is met or not met — "mostly"
   is not a result. If the goal was met while committed tasks were missed, or
   missed while every task shipped, that gap is the most interesting finding in
   the sprint.
4. **Check the sprint definition of done.** Did delivered work actually meet it,
   or was it waived under time pressure? Waived DoD is a finding, not an
   administrative detail.
5. **Close out prior actions.** Read the prior retrospective's action table. For
   each: done, still open, or abandoned. An action carried three sprints without
   progress is itself a finding — name it as one.
6. **Gather evidence, then find themes.** Work from what is observable — task
   statuses, dependency slippage recorded in the plan, CI or incident summaries,
   review turnaround. Group observations into themes; a theme supported by one
   anecdote is an anecdote.
7. **Write the actions.** Each action gets an owner, and a track naming the skill
   that will action it (see routing below). An action with no owner is a wish.
8. **Write the retrospective** using
   [assets/sprint-retro.template.md](assets/sprint-retro.template.md),
   then report the summary in chat.

## Action routing

Every action routes to where the work actually happens. This skill records the
routing; it does not perform the downstream change.

| Finding is about                         | Track     | Actioned by         |
| ---------------------------------------- | --------- | ------------------- |
| Epic scope, priority, or missing epics   | backlog   | **backlog-refine**  |
| Task breakdown, estimates, vague AC      | tasks     | **tasks**           |
| Architecture drift or an undocumented decision | architecture | **solution**, `adr plan <work-id>` |
| Stale or contradictory documentation     | docs      | **docs-review**     |
| Delivery phase or exit criteria wrong    | roadmap   | **roadmap**         |
| Code quality or review process           | delivery  | **code-review**     |
| Team process, ceremony, or working agreement | process | the team (no skill) |

## Quality rules

- Every finding must cite evidence: a task status, a date, a measurement, an
  incident, or a named dependency — not a feeling
- Committed-versus-delivered must be stated in numbers before it is narrated
- The sprint goal verdict is binary: met or not met
- Every action has an owner and a track; unowned actions are not recorded as
  actions
- Prior actions are all accounted for — done, open, or abandoned with a reason
- Findings describe systems and decisions, not individuals
- If the sprint met its commitment comfortably, say what capacity was left on
  the table — an under-committed sprint is as much a planning finding as an
  over-committed one

## Negative constraints

A retrospective MUST NOT:

- Verify acceptance criteria against the codebase → that is **validate**
- Rewrite `plan.md` to match what happened — the plan is the historical record
  of what was committed; amending it destroys the evidence
- Write task Gherkin, add epics, or edit architecture directly → record an
  action routed to **tasks**, **backlog-refine**, **solution**, or **adr**
- Attribute a failure to a named individual — describe the system that allowed it
- Record an action without an owner
- Invent metrics, velocity, or incident history not present in the context
- Serve as sign-off that a work item is complete → that is **validate**

## Output

Write `docs/work/sprint-{id}/retrospective.md` from the template. Report in chat:

- **Sprint goal** — met or not met, with the evidence
- **Commitment versus actual** — points and task counts, delivered / partial /
  not started / descoped
- **Definition of done** — held or waived, and where
- **Themes** — each with its supporting evidence
- **Actions** — owner and track for each
- **Prior actions** — closed, still open, or abandoned
- **Carry-over into the next sprint** — what **sprint-planning** must account for