 | Sprint Planning |
Overview
Sprint Planning is a meeting between the PO and Dev Team to strategically populate an upcoming sprint’s backlog.
Attendees
The PO attends, as do all members of the Dev Team, including the Scrum Master. It is essential that all members are there because each person’s expertise is needed in order to accurately estimate Story Points and to create an accurate, realistic plan for how each story will be built. It is also important that everyone have a clear understanding of the overall objectives of the Sprint.
Objective
The ultimate objective of Sprint Planning is to populate the upcoming sprint’s Sprint Backlog. In order to do so, all potential stories (at the top of the Product Backlog) must also be estimated during Sprint Planning.
Timing
The Sprint Planning session is usually held after the Sprint Retrospective but before the next sprint is to occur. The timing is important because planning too early could severely undercut the agile practice re-assessing progress and value between each iteration. Also, because it is extremely important that a Sprint be well-planned and with a constant length in order for strategically allocating resources at higher levels, Sprint Planning must absolutely occur before a new sprint is underway. Sprint Panning is time-boxed at 8 hours for a month-long sprint, so 4 hours for a more typical 2-week sprint.
Important Considerations
The Product Owner is responsible for the Product Backlog and therefore has ultimate say in what Stories (or backlog items) can be selected for the next sprint’s Sprint Backlog. The Dev Team owns the Sprint Backlog and has the ultimate say on how many of the Stories can fit into the sprint. The PO can come armed with burndown charts from previous sprints so that the team can be reminded of what their typical velocity has been, and therefore, how many story points they should be able to accomplish. The team will estimate the effort of each potential Story that might go into the upcoming Sprint Backlog, often by carrying out a process called, “planning poker.”
The Process
Sprint Planning begins with the PO explaining the general goal of the upcoming sprint, i.e., what the resulting product increment will be. This will be based on the items at the top of the Product Backlog, which the PO will also introduce. The Dev Team members will have the chance to discuss their understanding and request clarification as needed. The Dev Team will then estimate the Stories under consideration and give final feedback on what is actually possible to achieve during the sprint.
Planning Poker
Estimating effort/complexity is subjective. When it comes to determining how much work will be needed to build/accomplish something, everyone’s impression is different. Not only do different people notice and/or focus on different aspects of the challenge, but some people will always skew lower or higher than others in their estimates. Also, personality-wise, certain people are more assertive in a discussion. In order for the estimation process to be meaningful and effective, it is important for all team members’ opinions to be taken into account.
Planning Poker is a voting process that insures that everyone’s opinion has equal value and that all concerns are taken into consideration. After all, certain members might have a better understanding or sensitivity to potential issues that could hide complexity. In planning poker, each Dev Team member has a card for each story being considered. On the card, the member will write their estimate of the story, using the Story Points (see the fibonacci sequence section under Estimation for more info). The members will then present their cards to the entire group. If anyone’s estimate is higher or lower than the prevailing estimate, those team members are given the chance to explain their thought process. Then, taking those new perspectives into consideration, everyone votes again, and the process repeats until there is unanimous consensus on how many Story Points are represented by a given Story.
Once the final set of stories are placed onto the Sprint Backlog, the Dev Team will break them down into tasks and otherwise determine how everything will get built, and by whom, by the end of the sprint.
The team will then be ready to start the sprint.