Why I do not use story points for sprint planning
Hi, Habr! I present to you the translation of the article “Why I Don't Use Story Points for Sprint Planning” by Mike Cohn.
As described in Agile Estimating and Planning, I’m a big fan of story points to evaluate the backlog of a product. However, I also recommend evaluating the backlog of a sprint in hours rather than in story points. Why is this apparent contradiction? I previously wrote about the reasons. I recommend using different units of measurement (points and hours) for different backlog.
But I am often asked a related question that I want to ask here:
I'm curious why you are not using story points to plan a sprint. I thought that the meaning of measuring speed in story points was, in part, to determine how much we can take (or fix) in the sprint. Do you use story point only for long-term planning (for example, release planning)?
I do not use story points for sprint planning, because story points are a useful long-term measure. But points are not useful in the short term.
It would be appropriate for the team to say: “We have an average speed of 20 story points, and we have 6 sprints left, so we’ll end up with about 120 story points in these six sprints.”
It would be inappropriate for the team to say: “We have an average speed of 20 story points, so we will finish in the next sprint.” This does not work.
Suppose the basketball team is in the middle of its season. To date, they have played 41 games and have scored an average of 98 points per game. It would be appropriate to say: "We will probably score an average of 98 points per game in the remainder of the season." But they should not say before any particular game: “We have an average of 98, so we will take 98 today.” That is why I say that speed is a useful long-term predictor, but not a useful short-term predictor.
The speed will vary from sprint to sprint.
That's why I want teams to plan their sprints, looking at the backlog of the product, choosing one of the most important things they could do, breaking this element / user story backlog of the product into tasks and evaluating the tasks, asking themselves if they can take commitments to release this item backlog product and then repeated until they are filled. No discussion of story points. No speed discussion. We are talking only about commitments, and we decide how much we can accomplish by breaking the product backlog points into tasks and evaluating them.
When a team finishes planning a sprint in this way, it is likely that the number of story points that they unknowingly pursue should be close to their average, but it will change.
It will also be true that the team will perform 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 speed is reserved to refer to measuring the volume of work planned or completed, as indicated in the units used to estimate the backlog of the product (which I recommend using story points ).
About the author: Mike Cohn is one of the authors of the Scrum software development methodology. He is one of the founders of the Agile Alliance and the Scrum Alliance. He specializes in helping companies implement and improve the use of agile processes and methods for creating high-performance teams.
References: Agile Estimating and Planning, Mike Cohn, 2005.
PS Do you rate sprint backlog in hours or story points?
As described in Agile Estimating and Planning, I’m a big fan of story points to evaluate the backlog of a product. However, I also recommend evaluating the backlog of a sprint in hours rather than in story points. Why is this apparent contradiction? I previously wrote about the reasons. I recommend using different units of measurement (points and hours) for different backlog.
But I am often asked a related question that I want to ask here:
I'm curious why you are not using story points to plan a sprint. I thought that the meaning of measuring speed in story points was, in part, to determine how much we can take (or fix) in the sprint. Do you use story point only for long-term planning (for example, release planning)?
I do not use story points for sprint planning, because story points are a useful long-term measure. But points are not useful in the short term.
It would be appropriate for the team to say: “We have an average speed of 20 story points, and we have 6 sprints left, so we’ll end up with about 120 story points in these six sprints.”
It would be inappropriate for the team to say: “We have an average speed of 20 story points, so we will finish in the next sprint.” This does not work.
Suppose the basketball team is in the middle of its season. To date, they have played 41 games and have scored an average of 98 points per game. It would be appropriate to say: "We will probably score an average of 98 points per game in the remainder of the season." But they should not say before any particular game: “We have an average of 98, so we will take 98 today.” That is why I say that speed is a useful long-term predictor, but not a useful short-term predictor.
The speed will vary from sprint to sprint.
That's why I want teams to plan their sprints, looking at the backlog of the product, choosing one of the most important things they could do, breaking this element / user story backlog of the product into tasks and evaluating the tasks, asking themselves if they can take commitments to release this item backlog product and then repeated until they are filled. No discussion of story points. No speed discussion. We are talking only about commitments, and we decide how much we can accomplish by breaking the product backlog points into tasks and evaluating them.
When a team finishes planning a sprint in this way, it is likely that the number of story points that they unknowingly pursue should be close to their average, but it will change.
It will also be true that the team will perform 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 speed is reserved to refer to measuring the volume of work planned or completed, as indicated in the units used to estimate the backlog of the product (which I recommend using story points ).
About the author: Mike Cohn is one of the authors of the Scrum software development methodology. He is one of the founders of the Agile Alliance and the Scrum Alliance. He specializes in helping companies implement and improve the use of agile processes and methods for creating high-performance teams.
References: Agile Estimating and Planning, Mike Cohn, 2005.
PS Do you rate sprint backlog in hours or story points?