| name | pc-sprint-planning |
| description | Use when the team has sized work and must choose a realistic iteration scope, sequence, and ownership model that fits capacity and current risk. |
| metadata | {"phase":"03-planning","inputs":["task-list","estimate-set","risk-register"],"outputs":["sprint-plan"],"prerequisites":["pc-estimation"],"quality_gate":"Sprint scope matches capacity, dependencies and risks are visible, and the team can explain why this slice is achievable now","roles":["tech-lead","product-manager"],"methodologies":["all"],"effort":"small"} |
Sprint Planning
Choose the next iteration on purpose. A sprint plan is a capacity-constrained bet, not a wish list.
Context
Sprint planning turns a backlog of valid work into a realistic short-horizon commitment.
See context and anti-pattern notes.
Inputs
I/O contract notes define required inputs and authority.
Process
Step 1: Start From Capacity, Not Desire
Confirm the real capacity for the iteration: available people, external blockers, carry-over work, and operational load. Adjust for on-call or release overhead when relevant.
Step 2: Select Work That Fits the Goal
Choose the smallest set of tasks that:
- fits the available capacity
- preserves dependency order
- advances the sprint goal
- does not overload the team with too many simultaneous high-risk items
Step 3: Make Sequence and Ownership Explicit
Document:
- what starts first
- what can run in parallel
- where handoffs occur
- which tasks are stretch goals versus committed work
Step 4: Publish a Defensible Sprint Plan
The output should let anyone understand what the team is betting on, what was deferred, and which risks or assumptions could force replanning mid-sprint.
Outputs
Produce only declared outputs at their documented quality boundary.
Quality Gate
