For anyone who has read my book, Agile Estimating and Planning
, it should come as no surprise that I'm a big proponent of using story points to estimate a product backlog and for medium- to long-term planning. What you might not know, though, is that I do not recommend using points or velocity to plan a sprint.
To help explain why, let's consider an American football team, say the Denver Broncos. Let's suppose that halfway through the season, the Broncos statisticians calculate that the team has scored an average of 21 points a game. It is entirely appropriate for the Broncos to predict that the team will continue to average around 21 points a game for the rest of the season. It is not, however, logical for the organization to assume that the Broncos team will score exactly 21 points in the game this Sunday night.
Similarly, it is appropriate for a development team to say “We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, “We have an average velocity of 20 story points so we should commit to 20 points for this sprint.”
Points are too imprecise to be useful in the short-term. They need to averaged over at least a handful of sprints to become useful predictors. Velocity changes from sprint to sprint—usually not wildly, but it does vacillate. Teams, therefore, should plan their sprints by looking at the product backlog, selecting the one most important thing they could do, then breaking that product backlog item (user story) into tasks and estimating those tasks in hours. If a team can commit to delivering that product backlog item, the team brings it into the sprint. If the team cannot (that is, if the sprint is full), then the item is left in the product backlog. In other words, the team only commits to the stories it is capable of completing in a particular sprint.
In this type of commitment-driven sprint planning, teams don't need to discuss story points or velocity. Instead, they need to determine which items they can complete in the coming unique sprint. After planning a sprint this way the team can add up the story points on the items they’ve selected for the sprint—that should be reasonably close to their average velocity. (Product backlog items should still have been estimated in story points so that stories can be prioritized and longer-term plans made.) But because of the imprecision in any story-sized estimates, the sum will not always be exactly the team’s average velocity.
Do you want one short tip each week
from Mike to help you succeed with agile?