Guide
Sprint Planning Checklist: A Practical Guide
Sprint planning works best when the team has a clear structure and a realistic view of what it can deliver.
A good planning session is not about filling the sprint with as much work as possible. It is about making a realistic commitment based on priorities, team availability and the work itself.
Before the session
Good sprint planning starts before the meeting.
1. Review the backlog
Make sure the work under discussion is ready enough to plan.
- Clear priorities
- Updated requirements
- Appropriate story descriptions
- Acceptance criteria
- Known dependencies
- Relevant technical information
2. Check team availability
Understand who will be available and what time away from delivery is already planned.
- Annual leave
- Public holidays
- Training
- Other project responsibilities
- Planned support work
- Other significant commitments
3. Calculate sprint capacity
Estimate the realistic availability of the team before deciding how much work to bring into the sprint.
Team availability minus leave minus meetings and planned work = sprint capacity
Capacity is not a performance target. It is an input for a sensible planning discussion.
Calculate your Sprint Capacity4. Review recent delivery
Look at what the team actually completed recently and whether there were blockers or spillover.
- Completed work
- Spillover
- Major blockers
- Unexpected work
- Significant changes in scope
5. Check dependencies and risk
Identify work that depends on another team, vendor, API or approval before the item can be completed.
- Another team
- External vendors
- APIs
- Infrastructure
- Business approvals
- Other prerequisites
During the session
Once the team is in the planning session, the goal is to agree on what can realistically be delivered.
1. Agree on the Sprint Goal
The Sprint Goal gives the team a shared purpose and helps prioritise work during the sprint.
2. Review priority items
Focus on the highest-priority work first and make sure the team understands why it is important.
- What needs to be delivered?
- Why is it important?
- What does “done” mean?
- Are there unanswered questions?
- Are there dependencies?
3. Discuss complexity and uncertainty
Some work looks simple on the backlog but is more difficult to execute than expected.
- New technology
- Technical unknowns
- External dependencies
- Integration work
- Unclear requirements
- Large or complex changes
4. Confirm what the team can commit to
Use the capacity estimate to decide how much work is realistic. Then check the selected work against the Sprint Goal and the likely level of uncertainty.
After the session
Once the meeting is complete, the team should make the plan visible and easy to follow.
- Sprint Goal
- Selected backlog items
- Important dependencies
- Known risks
- Relevant constraints
What to record
- External dependencies
- Known technical risks
- Pending approvals
- Environment issues
- Resource constraints
Common mistakes
- Planning based only on velocity: Historical velocity is useful, but it doesn't tell you how available the team will be during the next sprint.
- Ignoring leave and other commitments: Assuming everyone has full availability can quickly lead to unrealistic plans.
- Filling 100% of capacity: Theoretical capacity isn't a target. Unexpected work and uncertainty are normal parts of software delivery.
- Bringing unclear work into the sprint: If important questions remain unanswered, the team should discuss whether the item is ready to be planned.
- Treating the sprint plan as unchangeable: A sprint plan is based on what the team knows at the beginning of the sprint. New information can emerge during execution.