From a6c857b1742878a14a5f5c5c5782f9eab6879fd7 Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Sat, 7 Mar 2026 09:45:21 +0100 Subject: [PATCH] chore(skills): add sprint retrospective to sprint-start lifecycle MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Insert A1b retrospective step between sprint close and version bump. Covers: what shipped, what didn't, what we learned, process notes. Process improvements are optional — only proposed when something was actually broken. Co-Authored-By: Claude Opus 4.6 --- .claude/skills/sprint-start/SKILL.md | 42 ++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/.claude/skills/sprint-start/SKILL.md b/.claude/skills/sprint-start/SKILL.md index 6cc7aeb7f..48d86b9ca 100644 --- a/.claude/skills/sprint-start/SKILL.md +++ b/.claude/skills/sprint-start/SKILL.md @@ -87,6 +87,48 @@ tooling/db/sprint stop This marks the active sprint as completed and lists carry-over candidates. Note the sprint number (N) from the output. +#### A1b. Sprint retrospective and review + +Before bumping the version, run a brief retro. Present the following to +the user: + +1. **What shipped** — list completed tickets with one-line summaries +2. **What didn't ship** — carry-overs and why (blocked, cut, deprioritized) +3. **What we learned** — open questions raised during the sprint (new Q-NNN + items), review findings that surfaced design gaps, and any assumptions + that turned out to be wrong +4. **Process notes** — what worked well, what was friction (e.g. dependency + chains that blocked teams, specs that were over/under-specified, + review cycles that caught real issues vs busywork) + +5. **Process improvements** — this is the most important section. Do NOT + skip it. Look for: + - Dependency chains that blocked teams — could the sprint have been + structured differently to avoid the bottleneck? + - Specs that were over-specified (wasted planning) or under-specified + (wasted iteration) — what's the right level of detail for this + project's current stage? + - Review cycles — did they catch real issues or create busywork? + - Agent coordination — were agents stuck, duplicating work, or idle? + - **Dig into the deeper why.** Don't stop at "the dependency chain + blocked the copy team." Ask: why was there a dependency chain? Was + the sprint structured wrong, or was the work inherently sequential? + Could Phase 0 have been done pre-sprint? Should we change how we + plan sprints going forward? + - If something went rough, understand the root cause — not just what + happened, but why the process allowed it to happen. + - If a concrete process change follows naturally, propose it. But do + NOT force improvements. If nothing was broken, say so and move on. + Unnecessary process changes are worse than no changes. + +Keep each section concise — a few bullet points, not a document. The +retro is a conversation checkpoint, not a report. Use `AskUserQuestion` +to let the user add their own observations and push back before proceeding. + +If the user raises items that should be tracked, create Q-NNN entries +or backlog tickets on the spot. If process changes are agreed, update +the relevant skill files or CLAUDE.md immediately — don't defer them. + #### A2. Bump the version The project version scheme is `v0.1.{sprint_number}`. After closing