Sprint Planning
Preparing for a Sprint
In addition to closing out the current sprint, the Product Owner and ScrumMaster should be preparing the product release backlog for the next sprint. Changes may still surface in the sprint review meeting, however, for the most part, the next set of user stories should be “right-sized” and prioritized to be tasked for the next sprint. This may require architectural review, meeting with customers, stakeholders or other dependent teams, research spikes to flush out technical feasibility and understanding, involving human factors on user interface prototypes, etc...
Sprint Planning Meeting Overview
The Sprint Planning meeting is a working session with the entire team. It is facilitated by the ScrumMaster, but participation is expected by the whole team. The meeting may last 2-4 hours for a 2-week sprint. The team determines the available hours in the sprint, optionally creates a sprint goal, identifies and estimate tasks for one story at a time selected by the product owner, and determines how much to commit to in the sprint. The Sprint Planning meeting is arguably the most important meeting to running an effective sprint. Shortcutting this process may lead to ineffective sprint execution and create problems for the sprint review and retrospective.
Determining Available Hours
Open the Sprint Planning meeting with a discussion of available hours in the sprint. This will include a calculation of how many team members are available for how many days and for what percentage of time. A typical allocation is to use 9 days in a 2 week sprint, 6 hours per day, for each team member. Reduce days for holidays, vacation, training, etc... Reduce hours per day for new team members, or those assigned responsibilities outside of the team. Use these hours to compare with estimates and help determine how much to commit to in the sprint.
Identifying a Sprint Goal (Optional)
Some teams find that creating a goal for the sprint helps set and align focus for the entire team. Other teams find that the goal of the sprint is to get each story that was committed done by the end of the sprint. Whichever the team decides, it should be clear by the end of the meeting what the goal is.
Story - Task breakdown
During the Sprint Planning Meeting, the Product Owner presents one story at a time. For each story, the team discusses (in detail) the tasks needed to accomplish the story. All analysis, design, code, test, documentation tasks should be created and estimated to less than 18 hours for a given task. After the team has identified and estimated all of the tasks, the team compares the estimated versus available sprint hours to determine if they can commit to completing the sprint.
Sprint Planning Conclusion
The output of Sprint Planning is the creation of the Sprint Backlog represented on a Sprint Task Board. Each story should have one or more estimated tasks that are unassigned.
In addition to closing out the current sprint, the Product Owner and ScrumMaster should be preparing the product release backlog for the next sprint. Changes may still surface in the sprint review meeting, however, for the most part, the next set of user stories should be “right-sized” and prioritized to be tasked for the next sprint. This may require architectural review, meeting with customers, stakeholders or other dependent teams, research spikes to flush out technical feasibility and understanding, involving human factors on user interface prototypes, etc...
Sprint Planning Meeting Overview
The Sprint Planning meeting is a working session with the entire team. It is facilitated by the ScrumMaster, but participation is expected by the whole team. The meeting may last 2-4 hours for a 2-week sprint. The team determines the available hours in the sprint, optionally creates a sprint goal, identifies and estimate tasks for one story at a time selected by the product owner, and determines how much to commit to in the sprint. The Sprint Planning meeting is arguably the most important meeting to running an effective sprint. Shortcutting this process may lead to ineffective sprint execution and create problems for the sprint review and retrospective.
Determining Available Hours
Open the Sprint Planning meeting with a discussion of available hours in the sprint. This will include a calculation of how many team members are available for how many days and for what percentage of time. A typical allocation is to use 9 days in a 2 week sprint, 6 hours per day, for each team member. Reduce days for holidays, vacation, training, etc... Reduce hours per day for new team members, or those assigned responsibilities outside of the team. Use these hours to compare with estimates and help determine how much to commit to in the sprint.
Identifying a Sprint Goal (Optional)
Some teams find that creating a goal for the sprint helps set and align focus for the entire team. Other teams find that the goal of the sprint is to get each story that was committed done by the end of the sprint. Whichever the team decides, it should be clear by the end of the meeting what the goal is.
Story - Task breakdown
During the Sprint Planning Meeting, the Product Owner presents one story at a time. For each story, the team discusses (in detail) the tasks needed to accomplish the story. All analysis, design, code, test, documentation tasks should be created and estimated to less than 18 hours for a given task. After the team has identified and estimated all of the tasks, the team compares the estimated versus available sprint hours to determine if they can commit to completing the sprint.
Sprint Planning Conclusion
The output of Sprint Planning is the creation of the Sprint Backlog represented on a Sprint Task Board. Each story should have one or more estimated tasks that are unassigned.
