Sprint Planning

Sprint Planning Skill

Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output.

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

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.

# 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:

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

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

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.