# Sprint Planning

Sprint planning is used to define the list of stories that a team will commit to building during a single sprint for a given release. Story points are assigned using the team's velocity as a guideline for determining how many story points can be committed to for a single sprint. This view is similar to the release planning view, but is targeted at the sprint level.

## Planning Poker

Planning poker is a method of estimating the sizes of user stories during sprint and release planning meetings. Team members discuss a user story for a short period of time, after which team members assign that user story a points estimate. This is often done using Fibonacci numbers (1, 2, 3, 5, 8, 13, and so on), where the lower numbers are easier to work on. The team members with the highest and lowest estimates defend their positions, after which team members re-assign that user story a points estimate.

The purpose of planning poker is to achieve a consensus among the team as to the relative sizing for all user stories that are candidates to be moved into a sprint backlog or to be worked on during any single sprint. The user story sizing estimates help product owners select the user stories with the highest business value.

User story size estimates are intended to show how much effort is required in order to complete the work on an individual user story. In general, user stories assigned a 1, 2, or 3 are user stories that can be completed in a single two week sprint by two or fewer team members. User stories assigned a 5 or an 8 are more difficult, may require many team members, may have dependencies on other user stories, or may be too big to complete during a single sprint. Some user stories with a 5 or an 8 sizing estimate should be broken down into smaller user stories. User stories assigned a 13 (or greater) are almost always too large to be worked on during a single sprint and should be broken down by product owners into smaller user stories.

That said, there should be no literal meaning associated with any particular number in the Fibonacci sequence other than the meaning your team learns to associate with them over time. Some teams use standard playing cards, with an Ace representing a 1 and a King representing a 13.

## Velocity

Velocity is a method of determining how many story points of work a team can commit to in a future sprint based on how many story points of work a team was able to complete in previous sprints. As a safe, general rule, a team should never commit to more story points in a sprint than their average velocity over the 2-4 previous sprints.

But velocity is more than a simple math exercise. There are good velocities. And there are bad velocities. How do you know one from the other? Some characteristics of a good velocity:
• Story points are measured independently of the size of the team.
• Story points are sized to include all of the business priorities and goals of the Agile project.
• Story points are sized to include dependencies on all team members.
• Story points are sized to account for dependencies on external teams, such as support, sales, or training.

Most characteristics of a bad velocity are simply the opposite of a good velocity, such as committing to a number of story points that is only based on the number of team members available during the sprint. Or not factoring the potential complexity of a new series of features as they relate to the amount of time your support organization will need to be ready for the upcoming product release, the amount of time it will take your sales team to learn how to successfully engage potential customers, or by not accounting for the amount of time it may take a training team (or a documentation team) to produce customer-facing material.