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 (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 "<sprint goal>" 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: 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 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.