sprint-planning
GitHub用于结构化并引导Sprint计划会议。根据团队速度、容量和待办事项生成Sprint目标、校准后的 backlog、容量计划、风险标志及会议议程，确保范围可交付且目标清晰。
Trigger Scenarios
Install
npx skills add mohitagw15856/pm-claude-skills --skill sprint-planning -g -y
SKILL.md
Frontmatter
{
"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 (brain/) exists, ground in it instead of re-asking for what you already know:
- Read first: priority
decisions/(what the team agreed matters), featureentities/, and openhypotheses/the sprint might test. Runpython3 ../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.
# 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.
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.
Version History
- a38bc30 Current 2026-07-05 11:44
