Sprint Planning

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 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.

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.

Good velocity? Bad velocity? The reality is that most Agile teams consistently live somewhere in-between. Business priorities change. Challenging defects are discovered. Team members get sick. External dependencies can be hard to predict. But a little strategy can go a long way. Your team's velocity is important. So it's equally important to consider your velocity within the context of the work that your team is doing and how it relates to your product's release cycle, your team's relationship to other teams, and so on. For example, a bad idea might be to switch your automated testing platform four times in one calendar year. Every time you change platforms, you may be removing valuable points from your velocity. Another way a little strategy can help is for the product owner to have a good idea of what the product roadmap looks like in relation to the work the team will be asked to do during the upcoming release. For example, if one feature enhancement requires your engineering team to reconfigure the back-end, it's probably better to do that work earlier in the release cycle rather than later.

A good velocity helps your team deliver as much value as possible. A good velocity is what your team wants. Your team will need to work hard to learn what its good velocity looks like. Sometimes the old adage "do less to do more" can help a team understand what their velocity should be. If your team finds itself consistently underperforming its story point commitments (even by a point or two, per sprint), or if your team finds itself consistently finishing stories on the very last day of the sprint, right before the sprint review, then your team should consider committing to fewer story points. Over the next 2-4 sprints, this will lower your team's velocity, but it will also give your team a chance to see if a smaller commitment translates into a more successful sprint.