Sprint Plan | CMPM171, Winter 16, Section 01

See also: template, evaluation

The overall goal of sprint planning is to organize and plan the activities that will occur during the upcoming sprint. Coming into the sprint planning meeting, teams will have their release plan, which identifies the user stories that were originally planned for this sprint. After the first sprint, teams will also have a list of any tasks or user stories that were not implemented in the previous sprint, and that may be rolled into the current sprint. During the sprint planning meeting, the team uses these inputs to determine which user stories will be implemented during this sprint (this may involve revising the release plan), and then to subdivide these user stories into a series of fine grain tasks to perform. Each task has an associated time estimate.

Sprint planning, done well, can take a long time. Subdividing user stories into tasks is challenging, and estimating the time for each task also takes time. Discussions about pushing user stories to future sprints or releases can be tense if it means a desired game feature might not get implemented. Your team should ensure they have a large block of time set aside for their sprint planning meeting.

The main activities of sprint planning are:

Determine user stories: Determine which user stories will be implemented during this sprint. This will ideally be the same as the user stories determined during the release planning meeting. If the sprint planning meeting finds that the release plan was too optimistic, then some user stories may need to be pushed out into later sprints, or the game design itself may need to be scaled back. If the final set of user stories for the sprint differs from those in the release plan, the release plan needs to be updated to account for the change. Part of determining user stories involves prioritizing these stories, from most important to least important for the sprint. The most important stories should be implemented first. Recall that CS 171 requires teams to create specific features during some sprints (website, gameplay metrics), and these required features will result in user stories for those sprints. Consult the release plan for the detailed list of required features. These required features cannot be pushed off to a later sprint (but may be pushed into earlier sprints, if desired).
Determine tasks: For each user story, the team must determine the fine-grain set of activities that are necessary to implement the user story. Each task should represent a project activity of no more than 6 hours in duration. If a task seems like it will take longer than this, it should be further subdivided into multiple tasks. Generally, smaller tasks are preferred to larger tasks. Each task needs to be written on an index card or post-it note, so it can be placed onto the project's scrum board. As a result, a task description is short, usually a sentence, or even just a few words.
Estimate tasks: For each task, the team should develop an estimate in ideal work hours. This is different from user story estimatation, in which the estimates are in story points, which are unitless. Task estimation is in ideal work hours, and represent a commitment by the team on how long they think they need to implement a give task. Planning poker should be used to estimate the number of work hours required for each task. If the final estimate is larger than 6 hours, the task should be divided into multiple sub-tasks (which are individually estimated). An ideal work hour represents the amount of work a person can perform under ideal conditions (no interruptions, computer problems, etc.) in one hour. Of course, work conditions are rarely ideal, and hence actual elapsed time to perform a task may be greater than ideal work hours.
Sanity check: Once all user stories are selected, prioritized, and decomposed into tasks, and those tasks are estimated, the team needs to look at the total amount of time required to implement all tasks, and compare that with the amount of time they can possibly work during the sprint. For early sprints, this is challenging, since your team does not know its velocity of task completion well. To begin, choose a conservative figure, such as 10-12 ideal work hours per team member per week. For a three week sprint, this means each team member can be assigned 30 ideal work hours of tasks. Since teams typically underestimate the time required to perform tasks, and ideal work hours are lower than actual work hours, the amount of time each team member actually spends in a week may be substantially larger than 10-12 hours. Don't worry about under-assigning work. If your team completes all of its tasks early, it is possible to take on an additional user story during this sprint. After 2-3 sprints, each team should have a strong understanding of its capacity for task completion, and can use this to do better assignment of tasks.

After estimating all tasks your team may discover that it does not have the capacity to implement all of the user stories it has selected for this sprint. In this case, the team needs to pick the top priority user stories and implement those, pushing off the others to later sprints. Of course, if enough user stories get pushed off, this means your game is dropping features, and may not realize all of the capabilities described in the game design document. Alternately, a team may decide to work harder, adding more ideal work hours per team member. This is risky, due to task under-estimation (things tend to take longer to accomplish than you would think), and the time demands placed by other classes. It is easy for someone to say they'll work long hours early in the quarter, but much harder for them to actually find the time when they have a project or an exam due in another class.

Once the final decomposition of user stories into tasks has been completed, there are still a few more tasks to complete:

Initial burndown chart: A burndown chart shows the team's progress at completing tasks and completing a sprint. The x-axis is measured in work days until the sprint is over, and the y-axis shows the total number of hours remaining in uncompleted tasks. For the initial burndown chart, this is simple. The y-axis should have one point at day 0, representing the sum of all task times in the sprint. The x-axis should be large enough to encompass the days remaining in the sprint. On this graph, draw the ideal burndown time, which is a linear line that goes from (total task time, 0 days) to (0, total work days in sprint). As the sprint progresses, the Scrum Master will maintain the burndown chart, which will show your team's progress towards completing the sprint, and allow the team to perform replanning in the middle of the sprint, if needed. Note that the burndown chart should be made in such a way that it will be easy to maintain. One approach is to create a spreadsheet, with a listing of all tasks. The chart can then be computed automatically by the spreadsheet.
Initial task assignment: Finally, at the end of the sprint planning meeting, each person on the team needs to understand their first task assignment. Ideally, people will be assigned to work on specific user stories, and can then start implementing tasks associated with that user story.