--- name: sprint-planning description: "Structure and facilitate sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning agendas. Produces a sprint goal, velocity-calibrated backlog, capacity plan, risk flags, and a structured sprint planning meeting agenda." --- # Sprint Planning Skill Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output. ## Reads from / Writes to the Brain If a [`professional-brain`](../professional-brain/SKILL.md) (`brain/`) exists, ground in it instead of re-asking for what you already know: - **Read first:** priority `decisions/` (what the team agreed matters), feature `entities/`, and open `hypotheses/` the sprint might test. Run `python3 ../professional-brain/scripts/brain_query.py ./brain ""` and carry each fact's provenance tag through. - **📥 Propose to the Brain:** after producing, propose logging the sprint commitment (goal + committed scope) as a `decisions/` record, provenance-tagged. Show it, get a yes, then write with `../professional-brain/scripts/brain_write.py … --commit` (append-only, dry-run by default). ## Proposes Actions Once the sprint is agreed, hand it to [`action-runner`](../action-runner/SKILL.md): it previews (dry-run, risk-rated), runs only what you approve via the connected action MCP, and records what was done back to the brain. Typical: **create a ticket per committed backlog item** and **set the sprint milestone** (🟡). This skill proposes; action-runner gates and runs — never silently. ## What This Skill Produces - **Sprint Goal** — single, outcome-focused sentence the whole team can rally around - **Sprint Backlog** — prioritised list of user stories with story point estimates and acceptance criteria - **Capacity Plan** — team availability breakdown accounting for holidays, meetings, and focus time - **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings - **Risk Flags** — blockers or dependencies that could derail the sprint ## Required Inputs Ask for (if not already provided): - Sprint duration (1 or 2 weeks) - Team size and velocity (average story points per sprint) - Top 3–5 backlog items or epics to pull from - Any known absences, holidays, or team events - Previous sprint's incomplete items (carry-overs) ## Sprint Goal Formula Use this structure: > "This sprint we will [deliver X outcome] so that [user/business benefit], measured by [success indicator]." Never write sprint goals as task lists. Always outcome-first. ## Story Point Calibration | Complexity | Points | Description | |---|---|---| | Trivial | 1 | Clearly understood, no unknowns | | Small | 2 | Straightforward, minor effort | | Medium | 3 | Some complexity, clear path | | Large | 5 | Complex, needs design or research | | Very Large | 8 | High uncertainty, may need splitting | | Epic | 13+ | Too large — must be split before sprint | Flag any item estimated at 8+ and recommend splitting. ## Capacity Formula ``` Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor Focus hours/day: 6 (accounting for meetings, Slack, admin) Availability factor: 0.7–0.85 depending on holidays/events Story points to commit = Historical velocity × Availability factor ``` ## Programmatic Helper This skill ships with a stdlib-only Python script that computes capacity instead of estimating it by hand. Use it whenever the team's numbers are known — it applies the availability and 80% commit-ratio rules consistently. ```bash # Quick estimate from flags python3 scripts/capacity_calculator.py --team 5 --days 10 --velocity 30 --availability 0.8 --carryover 5 # Detailed estimate from per-member availability (JSON via stdin or --input file.json) echo '{"sprint_days":10,"historical_velocity":40,"carryover_points":8, "members":[{"name":"Ada","available_days":10},{"name":"Linus","available_days":7}]}' \ | python3 scripts/capacity_calculator.py --input - ``` The script returns available focus hours, a velocity figure adjusted for real availability, the **recommended commitment** (capped at 80% of velocity), and the remaining **capacity for new work** after carry-overs. Run it first, then build the sprint backlog to fit the recommended number. Add `--json` to pipe the result into other tooling. ## Output Format ### Sprint [N] — [Start Date] to [End Date] **Sprint Goal:** > [Goal statement] **Team Capacity:** [X] story points available (based on [Y] team members, [Z]% availability) **Sprint Backlog:** | Priority | Story | Points | Owner | Acceptance Criteria | |---|---|---|---|---| | 1 | [Story title] | [N] | [Team member] | [When X then Y] | **Carry-Overs from Previous Sprint:** - [Item] — Reason for carry-over: [brief explanation] **Risks & Dependencies:** - [Risk description] → Mitigation: [action] **Sprint Planning Agenda:** - 00:00–00:10 — Review sprint goal and team capacity - 00:10–00:40 — Walk through backlog items, confirm estimates - 00:40–01:20 — Assign stories, identify dependencies - 01:20–01:50 — Review acceptance criteria per story - 01:50–02:00 — Confirm sprint commitment and close ## Guidelines - Always challenge stories missing acceptance criteria — flag them explicitly - Recommend the team commits to 80% of available capacity, not 100% - If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point - Highlight any story with unclear ownership as a blocker ## Deeper Materials This skill ships with support files — use them when they are available: - **`references/capacity-honesty.md`** — Capacity Honesty — the numbers teams lie to themselves about. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses. - **`templates/planning-worksheet.md`** — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated. ## Scoring Rubric (0–40) Score any output of this skill before handing it over; 32+ is ship-quality. | Dimension | 0 | 5 | 10 | |---|---|---|---| | Sprint goal quality | Goal is a task list ("do stories 1–8") or missing entirely | Outcome-flavoured but vague — not scoreable pass/fail at sprint end | Single outcome sentence with user/business benefit and a success indicator, unambiguously scoreable at sprint end | | Capacity honesty | Commitment assumes 100% of theoretical capacity; carry-overs ignored | Availability adjusted, but the 80% commit ratio is skipped or carry-over points not subtracted before pulling new work | Real availability (holidays, meetings, focus hours), carry-overs deducted first, and commitment capped at 80% of adjusted velocity | | Story readiness | Stories lack acceptance criteria, estimates, or owners | Most stories estimated and owned, but 8+ pointers are unsplit or acceptance criteria are untestable | Every story has one owner, calibrated points, and testable acceptance criteria; every 8+ pointer is flagged for splitting | | Risk & dependency surfacing | No risks or dependencies listed | Generic risks ("might slip") with no mitigations or owners | Specific blockers and cross-team dependencies, each with a concrete mitigation and a named owner | ## Quality Checks - [ ] Sprint goal is outcome-focused (not "implement X" — something like "users can do Y") - [ ] Team capacity is calculated using actual availability, not theoretical 100% - [ ] Every story has an acceptance criterion (flag any that don't) - [ ] Stories estimated at 8+ points are flagged for splitting - [ ] Carry-overs from last sprint are accounted for in capacity ## Anti-Patterns - [ ] Do not write sprint goals as task lists — goals must be outcome-focused and scoreable pass/fail at sprint end - [ ] Do not commit to 100% of available capacity — always recommend 80% to preserve slack for unplanned work - [ ] Do not carry stories with no acceptance criteria into the sprint — flag them as blockers before committing - [ ] Do not allow stories estimated at 8+ points into the sprint without splitting them first - [ ] Do not ignore carry-over items when calculating capacity — they consume capacity and must be accounted for before new work is pulled in ## Execution For tool-using or computer-use agents that can reach the team's tracker (Jira, Linear, GitHub Projects). Runtimes without tool access ignore this section and deliver the document. See [SKILLSPEC.md §5](../../SKILLSPEC.md) for the rules this block follows. ### Preconditions - The sprint plan above has been produced and **explicitly approved by a human** — never build a sprint from an unreviewed draft. - Tracker access is already authenticated in the agent's environment; the target board/project is named by the user. - A dry-run listing of intended changes has been shown and confirmed. ### Allowed actions - Create the sprint/iteration container with the approved name and dates. - Move the approved, already-existing backlog items into the sprint — only the items listed in the approved plan. - Set story-point estimates on those items to the approved values. - Post the sprint goal as the sprint description or a pinned comment. - Nothing else: no creating new issues, no deleting or closing anything, no editing item descriptions, no touching other sprints. ### Verification - Re-read the sprint from the tracker: item count and total points equal the approved plan; every moved item is in the sprint; sprint dates match. - Post the verification summary (items, points, dates) back to the user. ### Rollback - Undo = move the items back to the backlog and delete the empty sprint container. - Stop and ask a human if: any item in the plan no longer exists or changed since approval, the tracker rejects an action, or the board contains an active sprint with overlapping dates.