Sprint or Iteration Planning
Sprint (also known as Iteration) Planning is the activity that Agile teams perform to identify the features to be worked on during a sprint. A planning meeting takes place at the beginning of every sprint in which the team discusses the highest remaining prioritized backlog items and breaks them down into specific tasks and tests, and estimates the effort to complete them. Velocity and the teams past performance are used to determine the amount of work the team schedules into the sprint and commits to. Team members typically sign up for initial tasks during the meeting and then pick up additional tasks during the sprint.
Key Sprint Planning Activities
During sprint planning, teams:
- Review sprint capacity: Calculate available team hours based on team size, sprint length, and planned time off
- Prioritize backlog: Product owner presents highest priority stories from the product backlog
- Estimate and commit: Team estimates stories and commits to what they can realistically deliver
- Break down work: Decompose stories into technical tasks with hour estimates
- Identify dependencies: Surface any blockers or dependencies requiring coordination
- Set sprint goal: Articulate a clear objective that describes sprint success
Sprint Capacity and Velocity
Teams use historical velocity to guide sprint commitments. Velocity is the average number of story points (or hours) completed in recent sprints. For example, a team with an average velocity of 40 points should plan approximately 40 points of work for the upcoming sprint.
Sprint capacity represents available team hours during the sprint. Calculate capacity as: number of team members × hours per day × sprint length in days, adjusted for planned time off, meetings, and support work. A team of 6 people working an 8-hour day in a 10-day sprint has a base capacity of 480 hours, typically reduced to 350-400 hours after accounting for ceremonies, breaks, and overhead.
Breaking Stories into Tasks
After committing to stories, teams decompose each story into technical tasks. Tasks represent the specific work required to complete the story, such as:
- Write API endpoint
- Create database migration
- Implement UI components
- Write unit tests
- Perform code review
- Update documentation
Teams estimate tasks in hours (typically 2-16 hours per task) to understand the detailed work required and identify which team member will perform each task. This task breakdown ensures the team has a concrete plan for delivering each committed story.
Use Cases
Scrum Master Facilitating Sprint 15 Planning Meeting
A scrum master facilitates Sprint 15 planning for an 8-person team with a historical velocity of 45 points. They start by reviewing Sprint 14 results: the team completed 42 of 50 committed points (84%). The product owner presents 15 prioritized stories totaling 65 points. The team estimates their Sprint 15 capacity at 320 hours (accounting for one team member on vacation). They select stories totaling 48 points, slightly above velocity to account for Sprint 14 undercommitment. The team breaks down the selected stories into 85 technical tasks, each estimated between 2-12 hours. The scrum master confirms total task estimates (342 hours) align with capacity, and the team commits to the 48-point sprint.
Product Owner Adjusting Priorities During Sprint Planning
A product owner enters Sprint 22 planning with the top 10 backlog stories prioritized. During planning, the team identifies that Story 3 "Implement SSO" depends on infrastructure work not yet complete. The product owner re-prioritizes, moving Story 3 down and pulling up Story 11 "Enhanced Reporting" which has no dependencies. The team continues selecting stories in the adjusted priority order until they reach capacity. The product owner documents the SSO dependency in the backlog, ensuring it's resolved before Sprint 23. This real-time priority adjustment ensures the team commits to deliverable work without blockers.
Development Team Using Velocity to Prevent Overcommitment
A development team reviews their velocity data before Sprint 9 planning. Sprints 5-8 show velocities of 38, 41, 37, and 40 points (average 39). The product owner proposes 55 points of work for Sprint 9, hoping to accelerate delivery. The team references their velocity data, explaining that committing to 55 points (41% above average) risks failure and technical debt. They propose 42 points (slightly above average, accounting for process improvements). The product owner agrees, and the team successfully delivers 41 points in Sprint 9, maintaining quality and sustainable pace. The velocity data provides objective evidence for healthy capacity planning.
Team Breaking Down Large Story into Detailed Tasks
During Sprint 12 planning, the team commits to "User Profile Management" story (13 points). They break it into 12 tasks: Create user profile API (8 hours), Write profile validation logic (4 hours), Design profile UI mockups (4 hours), Implement profile edit screen (8 hours), Add profile photo upload (6 hours), Create profile privacy settings (5 hours), Write integration tests (6 hours), Perform security review (3 hours), Update API documentation (2 hours), Database migration script (3 hours), Deploy to staging environment (2 hours), Regression testing (4 hours). Total task estimates: 55 hours. The team assigns tasks to specific members based on expertise. This detailed breakdown ensures everyone understands the work required and can track progress throughout the sprint.
Scrum Master Identifying Sprint Goal During Planning
A scrum master guides Sprint 16 planning and notices the team selected 8 stories covering diverse areas: 3 UI enhancements, 2 bug fixes, 2 API improvements, and 1 performance optimization. They ask, "What's our sprint goal?" The team discusses and identifies that 6 of 8 stories relate to "Improving user onboarding experience." They articulate the sprint goal: "Streamline new user onboarding to reduce time-to-first-value." This clear goal helps the team make prioritization decisions during the sprint. When an urgent bug arises mid-sprint, they assess its impact on the sprint goal, deciding whether to include it or defer to Sprint 17 based on goal alignment.
Frequently Asked Questions
How long should sprint planning meetings take?
Sprint planning typically takes 2-4 hours for a two-week sprint, proportionally adjusted for different sprint lengths. For a one-week sprint, plan 1-2 hours; for a three-week sprint, allow 4-6 hours. The meeting length depends on team size, backlog readiness, and whether stories are already estimated. Teams practicing continuous backlog refinement (estimating stories before sprint planning) can complete planning faster than teams estimating during the meeting. If sprint planning regularly exceeds 4 hours for a two-week sprint, improve backlog refinement practices to pre-estimate stories and clarify acceptance criteria before planning.
What's the difference between velocity and capacity?
Velocity measures historical output in story points (or hours) completed per sprint, based on past performance. Capacity represents available team hours for the upcoming sprint, accounting for team size, sprint length, and known time off. Velocity guides how many story points to commit to; capacity validates whether estimated tasks fit within available hours. For example, a team with 40-point velocity and 320-hour capacity would commit to approximately 40 points of stories, then verify that the task breakdown totals near 320 hours.
Should we estimate stories in hours or points during sprint planning?
Most agile teams estimate stories in relative story points during backlog refinement, before sprint planning. Story points represent complexity and effort relative to other stories, abstracting away individual differences in productivity. During sprint planning, teams estimate tasks (not stories) in hours to understand detailed work and validate sprint capacity. The combination works well: story points for high-level story estimation and commitment, hours for low-level task planning and daily tracking. Avoid re-estimating stories in hours during sprint planning; if stories are already pointed, use those estimates for velocity-based commitment.
What happens if we select too many stories during sprint planning?
If the team commits to more work than their historical velocity suggests, they risk not completing all committed stories by sprint end. This leads to incomplete work rolling to the next sprint, reducing predictability and stakeholder confidence. If you realize mid-planning that selected stories exceed velocity, remove lower-priority stories to align commitment with capacity. Better to commit conservatively and deliver all committed work than overcommit and deliver partial work. Track velocity over multiple sprints to improve future sprint planning accuracy. Consistent overcommitment signals a need for better estimation or capacity understanding.
How do we handle urgent work that arises after sprint planning?
When urgent work arises mid-sprint, assess its priority against committed work. If truly urgent (production outage, security issue), add it to the sprint and remove lower-priority work of equivalent size to maintain capacity balance. Document the swap decision in sprint retrospective to understand disruption patterns. If the urgent work is important but not time-critical, add it to the backlog for the next sprint. Frequent mid-sprint scope changes suggest poor backlog management or unrealistic prioritization. Track these disruptions to identify improvement opportunities in release planning or stakeholder expectation management.
Should the product owner participate in task breakdown?
The product owner should attend the beginning of sprint planning to present priorities and answer clarification questions, but typically doesn't participate in detailed task breakdown. Task decomposition is a technical activity where the development team discusses implementation approach, technical dependencies, and work distribution. The product owner's time is better spent on backlog refinement and stakeholder communication while the team breaks down tasks. Some teams split sprint planning into two parts: Part 1 with the product owner to select stories and clarify requirements, Part 2 without the product owner for task breakdown and estimation.
How do we plan sprints when team members have varying availability?
Calculate sprint capacity individually for each team member based on their actual availability, then sum for total sprint capacity. For example, in a 10-day sprint: Member A (vacation 2 days) = 64 hours, Member B (full availability) = 80 hours, Member C (50% allocation) = 40 hours, Member D (training 1 day) = 72 hours. Total capacity = 256 hours. During task breakdown, consider individual availability when assigning tasks. Avoid assigning critical path work to members with limited availability. If multiple team members have reduced availability, consider reducing the sprint commitment accordingly rather than overloading the remaining team members.
What's a good sprint goal and why do we need one?
A good sprint goal is a concise statement describing what the sprint will achieve from a business or user perspective. Examples: "Enable mobile checkout for repeat customers", "Reduce page load times to under 2 seconds", "Complete MVP for admin dashboard". The sprint goal provides focus during the sprint, helping teams make trade-off decisions when unexpected issues arise. It also communicates sprint intent to stakeholders more effectively than listing individual stories. During sprint review, evaluate success based on whether the sprint goal was achieved, not just whether all stories were completed. A sprint that achieves its goal with 90% of stories complete may be more successful than one that completes 100% of stories without cohesive business value.
Related concepts
Understanding Digital.ai Agility User Interface
Understanding Roles and Project Membership
Understanding System (All Projects)
Using Tasks to Breakdown Stories Backlog Items
Sprint or Iteration Scheduling
Related tasks
Managing Stories Backlog Items