Planning
Sprint start
1-2 hrs
Daily Standup
Every day
15 min
Review
Sprint end
1 hr
Retro
Sprint end
1 hr
2 weeks
Typical sprint length
70-80%
Capacity utilization
5-10
Stories per sprint
What is Sprint Planning?
Sprint planning is an agile ceremony where the Scrum team collaboratively defines the work to be completed during the upcoming sprint. It answers two key questions: What can be delivered in this sprint? And how will the work be achieved? The output is a sprint backlog containing the selected user stories and a sprint goal that provides focus and direction.
Effective sprint planning sets the foundation for a successful sprint. When done well, the team leaves with a clear understanding of priorities, realistic commitments, and a shared sense of purpose. Poor planning leads to scope creep, missed commitments, and frustrated teams.
This template provides everything you need to run productive sprint planning sessions: a structured meeting agenda, capacity planning worksheets, and best practices from high-performing agile teams.
Sprint Planning Meeting Agenda (Copy-Ready)
A complete sprint planning agenda template covering both the "What" (scope selection) and "How" (task breakdown) phases. Customize timing based on your sprint length.
Sprint Planning Agenda Template
Complete meeting structure with checklists
# Sprint Planning Meeting Agenda ## Pre-Planning Checklist - [ ] Backlog refined (top items estimated and clarified) - [ ] Previous sprint reviewed (velocity calculated) - [ ] Team capacity determined (PTO, holidays accounted for) - [ ] Product Owner has priorities ready - [ ] Room/video call booked with screen sharing --- ## Part 1: The "What" (60-90 minutes for 2-week sprint) ### 1. Review Sprint Goal Candidates (10 min) - Product Owner presents 1-2 potential sprint goals - Team discusses feasibility and value - Agree on sprint goal **Sprint Goal:** _________________________________ ### 2. Review Team Capacity (10 min) | Team Member | Available Days | Notes | |-------------|----------------|-------| | | | | | | | | | | | | **Total Capacity:** _____ person-days **Target Velocity:** _____ points (based on last 3 sprints) ### 3. Select Backlog Items (30-45 min) Product Owner walks through prioritized backlog items. Team asks clarifying questions and confirms understanding. | # | User Story | Points | Acceptance Criteria Clear? | |---|------------|--------|---------------------------| | 1 | | | Yes / Needs clarification | | 2 | | | Yes / Needs clarification | | 3 | | | Yes / Needs clarification | ### 4. Confirm Sprint Scope (10-15 min) - Review selected items against capacity - Identify any dependencies or blockers - Get team commitment **Committed Points:** _____ **Stretch Goal (if applicable):** _____ --- ## Part 2: The "How" (60-90 minutes for 2-week sprint) ### 5. Break Down User Stories into Tasks (45-60 min) For each committed story, identify: - Technical tasks required - Who will work on what - Any spikes or research needed - Integration/testing tasks | Story | Tasks | Owner | Est. Hours | |-------|-------|-------|------------| | | | | | | | | | | ### 6. Identify Risks and Dependencies (15 min) | Risk/Dependency | Impact | Mitigation | |-----------------|--------|------------| | | | | | | | | ### 7. Final Commitment (10 min) - Team confirms they can deliver the sprint backlog - Review sprint goal one more time - Confirm Definition of Done --- ## Sprint Summary **Sprint Number:** _____ **Sprint Dates:** _____ to _____ **Sprint Goal:** _____________________________________ **Committed Stories:** _____ stories, _____ points **Key Risks:** _____________________________________ --- ## Post-Planning - [ ] Sprint backlog visible to all stakeholders - [ ] Sprint goal communicated to organization - [ ] First day's work is clear to everyone
Capacity Planning Template
Accurate capacity planning prevents overcommitment. Use this template to calculate your team's true availability and set realistic sprint goals.
Capacity Planning Template
Calculate team availability and velocity
# Sprint Capacity Planning ## Team Availability | Team Member | Role | Days in Sprint | PTO/OOO | Available Days | |-------------|------|----------------|---------|----------------| | [Name] | Dev | 10 | 0 | 10 | | [Name] | Dev | 10 | 2 | 8 | | [Name] | Dev | 10 | 0 | 10 | | [Name] | QA | 10 | 1 | 9 | | [Name] | Dev | 10 | 0 | 10 | **Total Available Days:** 47 days ## Focus Factor Calculation Not all available time is spent on sprint work. Account for: | Activity | % of Time | |----------|-----------| | Sprint work (stories/tasks) | 70% | | Meetings (standups, reviews, etc.) | 15% | | Support/interruptions | 10% | | Learning/improvement | 5% | **Effective Sprint Capacity:** 47 days × 70% = **33 effective days** ## Historical Velocity | Sprint | Committed | Completed | Velocity | |--------|-----------|-----------|----------| | S-3 | 34 | 32 | 32 | | S-2 | 35 | 35 | 35 | | S-1 | 38 | 33 | 33 | **Average Velocity:** 33 points **Recommended Commitment:** 32-35 points ## Capacity Adjustments - [ ] Major releases this sprint? (reduce by 10-20%) - [ ] New team members? (reduce their contribution by 50%) - [ ] Tech debt/refactoring planned? (allocate explicit time) - [ ] On-call rotation? (reduce on-call person by 20%)
Sprint Planning Best Practices
Do This
- +Refine backlog before planning (80% of items should be "ready")
- +Set a clear, measurable sprint goal
- +Base commitments on historical velocity
- +Break stories into tasks during planning
- +Account for PTO, meetings, and support work
Avoid This
- -Planning without a refined backlog
- -Letting stakeholders dictate scope during planning
- -Committing to more than velocity suggests
- -Skipping the "how" discussion (task breakdown)
- -Treating sprint planning as a formality
Common Sprint Planning Mistakes
Planning to 100% capacity
Problem: Teams commit assuming all hours are productive, leading to consistent overcommitment.
Solution: Use a focus factor of 60-70% to account for meetings, context switching, and unexpected work.
No sprint goal
Problem: Without a unifying goal, the sprint becomes a random collection of tasks with no focus.
Solution: Always define a sprint goal that explains the "why" behind the selected work.
Unclear acceptance criteria
Problem: Vague requirements lead to misalignment between what PO expects and what team builds.
Solution: Ensure every story has clear, testable acceptance criteria before planning.
Ignoring dependencies
Problem: Hidden dependencies cause blocked work and incomplete stories at sprint end.
Solution: Explicitly identify and discuss dependencies during planning; resolve or sequence accordingly.
Product Owner absence
Problem: Team cannot get clarity on requirements, leading to assumptions and rework.
Solution: Product Owner attendance is mandatory. Reschedule if PO cannot attend.
Frequently Asked Questions
What is sprint planning?
Sprint planning is a time-boxed Scrum ceremony where the team defines what work will be completed during the upcoming sprint and how that work will be achieved. It typically involves reviewing the product backlog, setting a sprint goal, selecting user stories, and breaking them down into tasks. The output is a sprint backlog with a clear commitment from the team.
How long should sprint planning take?
Sprint planning is typically time-boxed to 2 hours per week of sprint length. For a 2-week sprint, plan for up to 4 hours. For a 1-week sprint, 2 hours maximum. If planning consistently takes longer, consider refining backlog items better before planning, or the team may be trying to commit to too much work.
Who should attend sprint planning?
The core attendees are the Product Owner (to clarify requirements and priorities), the Scrum Master (to facilitate), and the Development Team (to estimate and commit). Stakeholders may attend as observers but should not dominate discussions. Everyone who will work on sprint items should be present.
What is a sprint goal and why is it important?
A sprint goal is a short statement describing what the team aims to achieve during the sprint. It provides focus and flexibility—if scope needs to be adjusted, the sprint goal guides decisions about what to keep or drop. Teams with clear sprint goals are more aligned and better at making tradeoffs during execution.
How do you calculate sprint capacity?
Sprint capacity is calculated by multiplying available team members by their available hours, then subtracting time for meetings, support work, and other commitments. For example: 5 developers × 8 hours × 10 days = 400 hours, minus 20% for meetings = 320 productive hours. Adjust based on PTO, holidays, and historical accuracy.
What is the difference between sprint planning and backlog refinement?
Backlog refinement (grooming) happens before sprint planning and focuses on clarifying, estimating, and prioritizing future work. Sprint planning focuses on selecting and committing to work for the immediate sprint. Well-refined backlogs make sprint planning faster and more effective. Refinement is ongoing; planning is a specific ceremony.
How many story points should a team commit to per sprint?
There is no universal answer—it depends on team velocity, which is the average points completed over previous sprints. Track velocity over 3-5 sprints to establish a baseline. New teams should start conservatively and adjust. Avoid comparing velocity between teams, as story point scales vary.
What happens if we cannot finish all sprint items?
Unfinished items return to the product backlog for re-prioritization. This is normal and not a failure. In the retrospective, discuss why items were not completed and how to improve estimation or scope management. Avoid the temptation to extend sprints or add overtime—this masks systemic issues.
About the Author
Aditi Chaturvedi
·Founder, Best PM JobsAditi is the founder of Best PM Jobs, helping product managers find their dream roles at top tech companies. With experience in product management and recruiting, she creates resources to help PMs level up their careers.