Modules and Views → Planning → Sprint Planning

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. How much work a team can do during a sprint is referred to as velocity. Each story or work item is assigned a value (typically known as a story point estimate) by the team. Velocity is the average estimated story points to which a team can commit over time. There are many ways to estimate story points and velocity. The most common approach is to use story points using planning poker as the way to determine the estimated size; however, other approaches include using shirt sizes (XL, L, M, S, and so on), affinity grouping (which seeks to identify similarities between stories and trends among stories over time), and so on.

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.

image

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. Or 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, your product's relationship to other products within your organization, and so on.

As best you can, you want to avoid disrupting your team to prevent having an adverse effect on its velocity. For example, switching your automated testing platform several times in one calendar year is probably a bad idea. 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.