Why I Don't Use Story Points for Sprint Planning

As described in [Agile Estimating and Planning](/books/agile-estimating-and-planning), I'm a huge fan of using story points for estimating the [product backlog](/agile/scrum/artifacts/product-backlog). However, I also recommend estimating the [sprint backlog](/agile/scrum/artifacts/sprint-backlog) in hours rather than in points. Why this seeming contradiction? I've [previously blogged on the reasons why](/agile/to-re-estimate-or-not-that-is-the-question) I recommend using different estimation units (points and hours) for the different backlogs. But I'm often asked this related question I want to address here:

I'm curious why you aren't using story points to do your sprint planning. I thought that the point of measuring story point velocity was partly to determine how much we can take on (or commit to) in a sprint. Do you only use story points for longer-term planning (e.g. release planning)?

I don't use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term. It would be appropriate for a 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 will finish in the next sprint." It doesn't work that way. Suppose a basketball team is in the middle of their season. They've scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say "We will probably average 98 points per game the rest of the season." But they should not say before any one game, "Our average is 98 therefore we will score 98 tonight." This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

Velocity will bounce around from sprint to sprint. That's why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It's just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called capacity-driven sprint planning.

When a team finishes planning a sprint in this way it is indeed likely that the number of story points they have unknowingly committed to should be close to their long-term average but it will vary some. It will also be true that a team will commit to approximately the same number of hours from one sprint to the next. I use the term capacity to refer to this number of hours because velocity is reserved for referring to measuring the amount of work planned or completed as given in the units used to estimate the product backlog (which I recommend be done using story points).

Last updated July 19th, 2023