Sprint planning is the most critical ceremony in Scrum. Get it right, and your team sets up a focused, achievable sprint that delivers value. Get it wrong, and you're looking at missed commitments, frustrated stakeholders, and a demoralized team.
This comprehensive checklist will guide you through every aspect of effective sprint planning in 2025, from pre-planning preparation to post-planning validation.
Understanding Sprint Planning
Sprint planning is a collaborative meeting where the team decides what work will be completed during the upcoming sprint and how that work will be achieved. The meeting has two main objectives:
- What: Which product backlog items will the team commit to completing?
- How: How will the team accomplish this work?
According to Scrum Guide 2025, sprint planning is timeboxed to a maximum of 8 hours for a one-month sprint. For shorter sprints, the meeting is proportionally shorter—typically 2 hours per week of sprint length. A two-week sprint would have a 4-hour timebox, while a one-week sprint would have 2 hours.
Remember that timeboxing specifies a maximum duration, not a minimum. If your team finishes planning effectively in 2 hours for a two-week sprint, that's perfect—don't fill time just because it's allocated.
Pre-Planning Preparation (1-2 Days Before)
Effective sprint planning starts before the meeting. Here's what should be ready:
Product Backlog Refinement Complete
The top 10-15 backlog items should be:
- Clearly written with INVEST-compliant user stories
- Include acceptance criteria
- Estimated with story points
- Ordered by priority (most valuable work at top)
- Dependencies identified and documented
Product owners should have refined these items in dedicated backlog refinement sessions, not during sprint planning itself. Sprint planning is for selection and commitment, not for clarifying vague requirements.
Historical Velocity Calculated
Calculate your team's rolling average velocity from the last 3-5 sprints. This becomes your baseline for sprint capacity.
Example: Last 5 sprints delivered 23, 26, 21, 24, 25 story points. Average velocity = 23.8 points. Round to 24 points for planning.
Team Availability Confirmed
Survey team members for upcoming sprint availability:
- Planned vacation days
- Conference attendance
- Training sessions
- Scheduled interviews (if applicable)
- Known production support duties
This information directly impacts capacity calculation during the meeting.
Definition of Done Reviewed
Ensure all team members understand current Definition of Done standards. If anything changed recently (new test coverage requirements, documentation standards, etc.), highlight this before planning.
Sprint Planning Meeting: Phase 1 (The "What")
Phase 1 focuses on selecting work and setting the sprint goal. Target duration: 50-60% of total planning timebox.
Step 1: Review Sprint Goal Context (15 minutes)
Product Owner presents:
- Progress toward product roadmap objectives
- Recent stakeholder feedback or market insights
- Key business priorities for this sprint
- Any dependencies or deadlines team should know about
This context helps the team understand why certain work is prioritized.
Step 2: Calculate Team Capacity (10 minutes)
Use this formula for capacity calculation:
Sprint Capacity = (Team Size × Sprint Days × Daily Hours × Focus Factor) ÷ Average Hours per Point
More commonly, teams use a simpler approach based on historical velocity:
Adjusted Capacity = Average Velocity × (Actual Availability ÷ Normal Availability)
Example:
- Team of 6 developers
- Normal capacity: 120 person-days per 2-week sprint (6 people × 10 days)
- This sprint: 2 people taking 2 vacation days each = 116 person-days available
- Historical velocity: 24 points
- Adjusted capacity: 24 × (116 ÷ 120) = 23.2 points ≈ 23 points
The 6.5-hour factor mentioned in some resources (instead of 8 hours/day) accounts for meetings, emails, and interruptions. This is already captured in your historical velocity, so don't double-count.
Step 3: Craft Sprint Goal (10 minutes)
The sprint goal is a concise statement of what the team aims to achieve. It should be:
- Outcome-focused: "Enable users to track order status" not "Complete 5 stories"
- Cohesive: Creates a unified theme for the sprint's work
- Negotiable: Specific enough to guide decisions but flexible on exact scope
- Valuable: Delivers something stakeholders care about
Good sprint goal: "Enable self-service password reset to reduce support ticket volume."
Bad sprint goal: "Complete items from the backlog."
Step 4: Select Product Backlog Items (60-90 minutes)
Working from the prioritized backlog, the team selects items until reaching capacity:
- Product Owner presents the highest-priority item
- Team asks clarifying questions about requirements and acceptance criteria
- Team confirms estimate or re-estimates if understanding changed
- Team commits to including item (or raises concerns/dependencies)
- Add points to running total
- Repeat until reaching capacity
Use planning poker for any items that need estimation or re-estimation.
Key checkpoint: After selecting items, verify they align with the sprint goal. If not, consider adjusting selections to improve cohesion.
Step 5: Identify Risks and Dependencies (10 minutes)
Before committing, discuss:
- External dependencies (other teams, third-party systems)
- Technical risks or unknowns
- Resource constraints (specialized skills, environments)
- Holiday impacts or other calendar issues
Document these as sprint risks. For high-probability/high-impact risks, consider reducing commitment or adjusting story selection.
Sprint Planning Meeting: Phase 2 (The "How")
Phase 2 focuses on understanding how the work will be accomplished. Target duration: 40-50% of total planning timebox.
Step 6: Break Stories into Tasks (60-90 minutes)
For each committed story, the team identifies implementation tasks:
- Database schema changes
- API endpoint development
- Frontend component creation
- Unit test writing
- Integration test creation
- Documentation updates
- Code review and revisions
- QA testing
- Deployment and smoke testing
Tasks can be estimated in hours (typically 1-8 hours) or left unestimated—different teams have different preferences. The goal is clarity on approach, not precise hour estimates.
Step 7: Assign Initial Owners (15 minutes)
While tasks can be reassigned during the sprint, initial ownership helps ensure balanced workload:
- Who has relevant expertise for each area?
- Are work streams distributed across the team?
- Are any individuals overloaded while others have light loads?
- Opportunities for pairing or knowledge transfer?
Avoid rigid assignment—agile teams swarm on work as needed. But initial distribution prevents "everyone's working on story A while story B sits untouched."
Step 8: Final Commitment (5 minutes)
The team collectively confirms:
- We understand what needs to be done
- We believe this work can be completed within the sprint
- We commit to achieving the sprint goal
- We'll communicate immediately if circumstances change
This is the team's commitment, not the Scrum Master's or any individual's. Everyone must agree before proceeding.
Post-Planning Validation
After the meeting, validate your plan:
Capacity vs. Commitment Check
Plot your commitment against calculated capacity:
- Under 80% capacity: May indicate sandbagging or overly conservative estimation
- 80-95% capacity: Healthy range allowing for some unknowns
- 95-105% capacity: Ambitious but achievable if no major risks
- Over 105% capacity: Overcommitment risk—consider removing lowest-priority items
Goal Alignment Check
Review committed stories and ask: "If we complete only 70% of committed work, will we still achieve the sprint goal?" If not, reconsider which stories are truly essential.
Documentation Complete
Ensure your sprint planning artifacts are captured:
- Sprint goal published in team wiki/board
- Committed stories moved to "Sprint Backlog" status
- Tasks created and assigned in tracking tool
- Identified risks documented
- Capacity calculation recorded for future reference
Common Sprint Planning Mistakes
Mistake 1: No Backlog Refinement
Teams that try to clarify requirements during sprint planning waste the entire timebox on Q&A instead of commitment and task breakdown. Refinement should happen continuously throughout the sprint, not in the planning meeting.
Mistake 2: Product Owner Dictates Commitment
The team decides what they can commit to, not the product owner. A PO saying "you must commit to 35 points" violates the self-organizing principle and leads to failed sprints.
Mistake 3: Ignoring Velocity Data
Your historical velocity is your best predictor of future capacity. Teams that ignore this data in favor of "trying harder" consistently overcommit and underdeliver.
Mistake 4: Vague Sprint Goals
"Complete high-priority items" isn't a sprint goal—it's a description of every sprint ever. A real sprint goal creates focus and enables trade-off decisions during the sprint.
Mistake 5: No Task Breakdown
Teams that skip task breakdown often discover implementation complexity mid-sprint that could have been identified during planning. Five minutes of task discussion can prevent two days of wasted effort on the wrong approach.
Remote Sprint Planning Adaptations
For distributed teams, adjust your approach:
Use Digital Tools Effectively
- Virtual planning poker tools for estimation
- Shared digital boards (Miro, Mural) for task breakdown collaboration
- Video conferencing with screen sharing for backlog review
- Breakout rooms for parallel task breakdown by story
Check out our guide to effective remote planning poker sessions for detailed best practices.
Account for Time Zones
If your team spans multiple time zones:
- Rotate meeting times to share the burden of off-hours meetings
- Consider async pre-work (capacity calculation, initial story review)
- Record sessions for team members who can't attend live
- Use written summaries in addition to verbal discussion
Our comprehensive guide on remote Scrum challenges offers additional strategies.
Combat Video Fatigue
- Schedule 5-minute breaks every 45 minutes
- Use cameras-off periods for individual task breakdown work
- Leverage polls and reactions to keep engagement high
- Assign a dedicated facilitator to manage energy levels
Sprint Planning Templates and Tools
Several tools streamline sprint planning:
- Jira: Sprint planning view with drag-and-drop, capacity tracking, and velocity charts
- Azure DevOps: Sprint planning boards with capacity management per team member
- Linear: Streamlined sprint planning with automatic capacity warnings
- Miro/Mural: Visual collaboration for task breakdown and estimation
Whichever tool you choose, ensure it supports:
- Historical velocity tracking
- Capacity calculation assistance
- Real-time collaboration for distributed teams
- Export of planning artifacts for documentation
Measuring Sprint Planning Effectiveness
Track these metrics to improve your planning over time:
- Sprint commitment accuracy: Target 85-95% (completed points ÷ committed points)
- Planning meeting duration: Should decrease as team matures and refinement improves
- Mid-sprint scope changes: Should be rare (under 10% of committed work)
- Sprint goal achievement: Did you meet the goal even if not all stories completed?
- Team confidence rating: Survey team after planning: "How confident are you in this sprint plan?" Track trends.
Your Sprint Planning Checklist
Use this checklist to ensure comprehensive planning:
Pre-Planning (48 hours before)
- ☐ Top 10-15 backlog items refined with acceptance criteria
- ☐ All refined items estimated in story points
- ☐ Historical velocity calculated (3-5 sprint average)
- ☐ Team availability confirmed for upcoming sprint
- ☐ Definition of Done reviewed with team
- ☐ Product owner prepared business context and priorities
- ☐ Meeting invite sent with pre-read materials
During Planning
- ☐ Product owner presents business context (15 min)
- ☐ Team calculates adjusted capacity (10 min)
- ☐ Sprint goal crafted collaboratively (10 min)
- ☐ Stories selected from backlog up to capacity (60-90 min)
- ☐ Dependencies and risks identified (10 min)
- ☐ Stories broken down into tasks (60-90 min)
- ☐ Initial task ownership assigned (15 min)
- ☐ Team commits to sprint goal and selected work (5 min)
- ☐ Total planning time within timebox
Post-Planning
- ☐ Commitment vs. capacity validated (80-105% range)
- ☐ Sprint goal published visibly
- ☐ Sprint backlog updated in tracking tool
- ☐ Tasks created and assigned
- ☐ Risks documented
- ☐ Capacity calculation recorded
- ☐ Planning artifacts accessible to stakeholders
Conclusion: Planning Enables Predictability
Effective sprint planning is the foundation of predictable delivery. When teams invest time in thorough planning—with refined backlogs, accurate capacity calculation, clear sprint goals, and detailed task breakdown—they set themselves up for successful sprints that build stakeholder trust.
Use this checklist to ensure your planning meetings are comprehensive yet efficient. Track your commitment accuracy over time. Continuously improve your refinement process to make planning smoother.
Remember: the goal isn't perfection, it's predictability. Aim for 85-95% commitment accuracy sprint after sprint, and you'll build a reputation as a team that delivers what they promise.
Want to improve your agile practices? Explore our guides on estimation techniques and discover more resources across the Journaleus network.