Explains the sprint planning process in Scrum methodology, including participants, sprint goals, and creating the sprint backlog. Covers how the development team selects stories, confirms story points, and ensures each story has sufficient details for implementation during the upcoming sprint.
Sprint planning is a critical Scrum meeting where the product owner, Scrum master, and development team determine which stories from the product backlog will be included in the upcoming sprint. This meeting establishes the sprint goal, confirms story point estimates, ensures stories have sufficient details, and creates a sprint backlog with stories that match the team's velocity.
Sprint planning is a fundamental component of the Scrum framework that follows product backlog refinement and precedes the actual sprint execution. This meeting determines which user stories will be implemented in the next sprint and how much the team can accomplish within the sprint timeframe.
The primary output of sprint planning is the sprint backlog, which contains all the stories the team commits to completing during the sprint. This selection of stories is based on priorities defined in the product backlog and the team’s capacity to deliver work within the sprint duration.
Sprint planning is a focused meeting that requires participation from specific team members to ensure effective planning and commitment.
| Role | Responsibility |
|---|---|
| Product Owner | Articulates the sprint goal and clarifies business priorities |
| Scrum Master | Facilitates the meeting and helps resolve any impediments |
| Development Team | Selects and commits to stories, confirms story points |
Unlike other Scrum events, sprint planning does not include stakeholders or other external participants. It is exclusively for the core Scrum team members. The development team in this context refers to all team members involved in building the product, including software engineers, testers, operations specialists, and potentially business analysts - essentially a cross-functional team rather than just programmers.
Each sprint should have a clearly defined goal that provides focus and direction for the team throughout the sprint execution.
The product owner is responsible for articulating the sprint goal, which should describe what capability or value will be delivered by the end of the sprint. Rather than thinking about completing the entire product, the goal should focus on what can realistically be accomplished within the sprint timeframe (typically two weeks).
The sprint goal serves several important purposes:
When team members understand the underlying goal of the sprint, they can make better decisions about implementation details and avoid going off on tangents that don’t contribute to the sprint’s objective. During the sprint, the goal serves as a reference point to ensure everyone remains aligned with the intended outcome.
The sprint planning process involves several concrete steps carried out primarily by the development team.
The development team takes stories from the top of the product backlog and moves them into the sprint backlog. This process continues until the team’s velocity (capacity) is reached. During this selection process, the team:
Even if stories already have point estimates from backlog refinement, the development team should confirm these estimates since they are the ones committing to delivery. Some teams use techniques like Planning Poker, where team members simultaneously reveal their individual estimates (e.g., “This is a 3” or “This is a 5”) and then discuss any differences until consensus is reached.
A critical aspect of sprint planning is ensuring that each selected story contains all the information needed for implementation. Team members should be able to start working on any story in the sprint backlog without needing to ask additional questions. This completeness helps maintain sprint momentum and prevents delays during execution.
Team velocity is a key metric in sprint planning that represents the number of story points a team can complete in a single sprint.
Velocity is determined by summing the story points of all completed stories in a sprint. This metric is specific to each team and will naturally evolve over time as:
A critical point about velocity is that it cannot be fairly compared between different teams. This limitation exists because:
| Factor | Impact on Comparability |
|---|---|
| Estimation Scale | Teams may use different scales (e.g., one team uses 1-3-5 while another uses 3-5-8) |
| Definition of “Medium” | What constitutes a medium-sized story varies between teams |
| Team Context | Different domains, technologies, and team compositions affect what can be accomplished |
For example, if one team defines a medium story as 2 points while another defines it as 5 points, the second team will appear to have higher velocity even if both teams complete the same amount of work. This makes velocity a team-specific metric that should only be used to track a single team’s progress over time, not for comparative evaluation between teams.
Most project management tools provide mechanisms for organizing work into sprints or milestones.
When starting sprint planning, creating a milestone (or sprint in some tools) helps track and organize the work. This typically involves:
While sprint length can vary, two-week sprints are commonly used because:
The two-week cadence establishes a regular rhythm for development and delivery that works well for most teams.
Sprint planning is a critical meeting that bridges the gap between the product backlog and actual sprint execution. By establishing clear goals, confirming story points, ensuring stories are fully defined, and respecting the team’s velocity, sprint planning sets the foundation for successful sprint execution. The sprint backlog created during this process represents the team’s commitment to delivering specific functionality within the sprint timeframe, aligned with the overall sprint goal.
(2) Sprint planning is a meeting where the product owner, Scrum master, and development team determine which stories from the product backlog will be included in the upcoming sprint. This meeting establishes the sprint goal, confirms story point estimates, and creates a sprint backlog with stories that match the team’s velocity.
(3) Without a clearly defined sprint goal, team members may lose focus and make inconsistent implementation decisions. The sprint goal provides context for implementation decisions, helps prevent scope creep and over-engineering, and guides the team when questions arise during development. Without this clarity, the team lacks a reference point to ensure everyone remains aligned with the intended outcome.
(2) After establishing a sprint goal, the team should select stories from the top of the product backlog that align with that goal. The development team takes stories from the top of the product backlog and moves them into the sprint backlog, continuing until the team’s velocity is reached. They would review each story to ensure it aligns with the sprint goal before including it in the sprint backlog.
(3) It is incorrect that velocity can be used to compare performance between different teams. Velocity is team-specific and cannot be fairly compared between teams because each team may use different estimation scales, have different definitions of what constitutes a “medium” story, and work in different contexts. Velocity should only be used to track a single team’s progress over time.
(2) Using an average of approximately 23-24 points as a starting guideline for capacity is most likely correct. Velocity typically evolves over time, and using a running average from recent sprints provides a reasonable baseline for planning. This approach recognizes the team’s demonstrated capacity while accounting for normal fluctuations in productivity.
(4) Stakeholders are not required participants in sprint planning. Sprint planning is exclusively for the core Scrum team members - the Product Owner, Scrum Master, and Development Team. Unlike other Scrum events, stakeholders or other external participants are not included in this meeting.
(2) A team that consistently takes more stories into their sprint than they can complete likely does not properly understand or use their velocity for planning. This pattern suggests they are not basing their sprint commitments on their demonstrated capacity (velocity) from previous sprints, which is a fundamental aspect of effective sprint planning.
(2) When high-priority stories lack sufficient details during sprint planning, the team should first check if the stories were properly refined during backlog refinement. One of the primary purposes of backlog refinement is to ensure that high-priority stories contain enough information to be implemented without needing additional clarification during the sprint.
| Concept | Description |
|---|---|
| A. Sprint Goal | 1. The output of sprint planning containing committed stories |
| B. Sprint Backlog | 2. A technique where team members simultaneously reveal their estimates |
| C. Planning Poker | 3. A clear statement of what capability will be delivered in the sprint |
| D. Team Velocity | 4. The number of story points a team can complete in a single sprint |
A-3, B-1, C-2, D-4. The Sprint Goal is a clear statement of what capability will be delivered in the sprint. The Sprint Backlog is the output of sprint planning containing committed stories. Planning Poker is a technique where team members simultaneously reveal their estimates. Team Velocity is the number of story points a team can complete in a single sprint.
During sprint planning, the development team should accept all story point estimates created during backlog refinement without further discussion.
False. Even if stories already have point estimates from backlog refinement, the development team should confirm these estimates during sprint planning since they are the ones committing to delivery. The development team decides how big a story is, and they need to be comfortable with the story points assigned.
(2) A two-week sprint duration is commonly recommended because it provides a balance between delivering meaningful functionality and responding to changing requirements. One-week sprints may be too short to deliver meaningful functionality, while longer sprints (3-5 weeks) risk being affected by changing requirements. The two-week cadence establishes a regular rhythm for development and delivery that works well for most teams.