| name | sprint-plan |
| description | Plans a sprint with capacity estimation, story selection, dependency mapping, and risk identification. Use when preparing for sprint planning, estimating team capacity, or balancing scope against velocity. Triggers on: sprint planning, sprint plan, capacity planning, sprint scope, story points, sprint goal, backlog grooming, sprint prep, what do we build this sprint. |
Sprint Plan
Core Philosophy
Sprint planning is a commitment, not a wish list. The goal is not to stuff the sprint with as many stories as possible — it's to make a realistic promise the team can keep. An under-committed sprint that ships is better than an over-committed sprint that leaves things half-done.
The sprint goal is the contract. Every story in the sprint should directly serve it.
When to Use
- Before the start of a new sprint
- When backlog needs to be sequenced and stories need capacity estimates
- When a sprint is at risk and scope needs to be cut
Workflow
1. Set the Sprint Goal
One sentence. What does success look like at the end of this sprint — from a user or business perspective, not an engineering perspective?
- Bad: "Complete stories 45-52"
- Good: "Users can complete onboarding without contacting support"
The sprint goal is the tiebreaker when scope decisions arise mid-sprint.
2. Estimate Team Capacity
- List each team member and their availability (working days minus PTO, holidays, on-call)
- Reference velocity from the last 3 sprints (average story points completed)
- Apply a 15-20% buffer for unexpected work, bugs, and interruptions
- Result: Available capacity in story points for this sprint
3. Select Stories from the Prioritized Backlog
- Pull from the top of the prioritized backlog (highest priority first)
- Each story must meet the Definition of Ready: clear acceptance criteria, estimated, no open blockers
