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 use cases 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 Use Cases that the team feels it can commit to completing in the sprint, based on experience with previous sprints. After the use cases have been identified, you can use the Use Case Planning workbook to assign them to the sprint. For more information, see Use Case Planning Workbook.
In the second part of the meeting, your team determines how it will develop and test those Use Cases. Your team then breaks those Use Cases down into tasks and estimates the work that is required to complete them. Finally, your team commits to implementing some or all of the Use Cases based on these estimates.
In the first part of the meeting, your product owner meets with your team to discuss the Use Cases that might be included in the sprint. Your product owner will share information and answer any questions that your team has about those use cases. 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 Use Cases. During this part of the meeting, your team learns what it must build.
After your team has discussed all of the details about the use cases 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 Use Cases and whether it can commit to implementing all the scenarios in the Use Case that your product owner requested. To better understand what is involved in completing each Use Case, your team breaks down each use case into the tasks that your team must perform to implement that use case 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 Task Backlog workbook to break Use Cases down into tasks. For more information, see Iteration Task 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 Use Case.
Your team continues to analyze each Use Case and estimate its tasks until your team determines that it has enough use cases 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 Task 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 Task Backlog Workbook.
You should alert your product owner if your team determines that it cannot complete one or more of the use cases that your product owner has requested because its task estimates exceed the number of available hours. Your product owner might substitute a smaller use case, split the use case, or hold the use case 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 Use Case
-
committed to the Use Cases that it will deliver in the sprint
-
understood, as a self-organizing team, how it will work together to meet its commitments