Sprint Planning Meeting
Your team builds the sprint backlog in the planning meeting on the first day of the sprint. At this meeting, your product owner works with your team to determine which stories it will complete in the sprint. The planning meeting has two parts, and each half is limited to half of the total length of the meeting. In the first part, your team and your product owner identify the user stories that the team feels it can commit to completing in the sprint, based on experience with previous sprints. After the user stories have been identified, you can use the Product Planning workbook to assign them to the sprint. For more information, see Product Planning Workbook.
In the second part of the meeting, your team determines how it will develop and test those user stories. Your team then breaks those user stories down into tasks and estimates the work that is required to complete them. Finally, your team commits to implementing some or all of the user stories based on these estimates.
In the first part of the meeting, your product owner meets with your team to discuss the user stories that might be included in the sprint. Your product owner will share information and answer any questions that your team has about those stories. This conversation might reveal details such as data sources, user interface layout, response time expectations, and considerations for security and usability. Your team should add these details to the user stories. During this part of the meeting, your team learns what it must build.
After your team has discussed all of the details about the user stories that it feels are necessary, your ScrumMaster starts the second part of the planning meeting. Your product owner should attend this part of the meeting to help clarify requirements and to help understand and select alternatives. The ScrumMaster facilitates this part of the meeting as your team determines how it will implement the user stories and whether it can commit to implementing all the stories that your product owner requested. To better understand what is involved in completing each user story, your team breaks down each story into the tasks that your team must perform to implement that story and to ensure that it is finished. You might find the following example tasks in the sprint backlog: "Update the stored procedure to use the new data feed" and "Create the class for the collector web service."
Your team can use the Iteration Backlog workbook to break user stories down into tasks. For more information, see Iteration Backlog Workbook.
The team then estimates how many hours of work each task will require. Because the tasks are not assigned before they are estimated, the team works together to create these estimates. (Teams often cannot identify and estimate all work during the sprint planning meeting. As much as 40% of the work that a team completes during a sprint emerges after the sprint planning meeting).
The planning poker technique is a good tool for estimating task hours. By using this tool, each team member can participate in estimation, instead of depending on the subject matter experts to estimate their own tasks. Whether you use this technique or another, you should involve the whole team in determining how many hours each task will take. For more information, see the following Web resource: Planning Poker.
Tasks should take no more than a day to complete. If a task is too large, the team should break it down. In some cases, you may not be able to estimate some tasks effectively until other tasks have been completed. Create the task now, but estimate it when you have enough information. Individual task estimates are added together to determine how many hours the team will likely require to complete each user story.
Your team continues to analyze each user story and estimate its tasks until your team determines that it has enough stories for the sprint. Your team makes this determination by comparing the number of estimated hours to the number of hours that the team expects to complete in the sprint.
You can use the team capacity worksheet in the Iteration Backlog workbook to help determine your team's capacity for the sprint. You must fill in the details of the sprint in the settings worksheet. To account for vacation, holidays, and other interruptions, you must fill out the interruptions worksheet. For more information, see Iteration Backlog Workbook.
You should alert your product owner if your team determines that it cannot complete one or more of the stories that your product owner has requested because its task estimates exceed the number of available hours. Your product owner might substitute a smaller user story, split the story, or hold the story in the product backlog for a future sprint. After your team completes both parts of the planning meeting, it has accomplished the following:
created the sprint backlog, with tasks and hours for each user story
committed to the user stories that it will deliver in the sprint
understood, as a self-organizing team, how it will work together to meet its commitments
See Also
Concepts
Planning and Tracking Projects