Sprint planning meetings are held before the start of each sprint and are attended by product owner, scrum master and the entire development team. During the meeting the product owner describes the goal of the upcoming sprint and prioritizes the backlog of user stories based on that goal. The sprint goal is a concise description of what the sprint team plans to achieve in the upcoming sprint. An analogy can be made between the sprint goal and an epic story; the sprint goal is a high level description of what the development team will be working on during the sprint and is not intended to include low level implementation details. The sprint goal summary can be used by the sprint team to communicate what the team is focusing on to stakeholders outside the sprint.
The development team then discusses the prioritized user stories with the product owner, capturing the details needed to implement them. The product owner and the development team typically aim to discuss two sprints worth of stories to ensure that each story that ends up in the sprint backlog has been addressed. Any stories that are covered in this meeting that do not make it to the sprint backlog will remain in the scrum backlog until they are added to a future sprint or removed to account for changing requirements.
Once the backlog of user stories has been prioritized to match the sprint goal the development team works together to estimate the effort required for each user story. User story effort can be estimated several different ways but, at Bloomy, we like a method called Planning Poker. We practice this technique through the software we use to manage our scrum processes, but it can be done by hand just as well—the following paragraph describes the latter.
To start a round of planning poker the scrum master selects a user story from the backlog and reads it to the development team. Each member of the development team then considers the relative amount of effort required to implement the feature and selects one card from a deck of index cards (with values of 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, Infinite) that they believe reflects this effort. It is important to understand that these effort estimates are unitless, meaning that the team is actually estimating a relative amount of effort and not an absolute number of hours. As an example, when we go to the movie theater we order a large popcorn, and not a 48 ounce popcorn; the volume of popcorn that makes up a large may differ between theaters but will always be in the same ballpark.
Once the prioritized user stories have been assigned unitless effort estimations the product owner might reprioritize the backlog. If a user story that the product owner assumed would be easy to implement received a high effort estimate, then the product owner may consider lowering its priority in the interest of getting more stories higher up in the backlog. Likewise, if a story the user manager had assumed to be technically challenging came back with a low estimate, the product owner may consider moving it up the list to ensure that it gets completed in the upcoming sprint.
With the prioritized backlog finalized, the development team selects the top N user stories whose effort estimates sum to the number of points they are typically able to complete in one sprint. If a development team is typically able to complete 400 points, and the top 15 user stories total to 398 points then the team will select those 15 user stories and use them as the sprint backlog. The team then works through these stories to complete the sprint.