There is a constant, long drawn debate on the benefits of using either story points or hours for sprint planning. Each camp seems to have its own set of reasons of taking one approach over the other. Mike Cohn is big on breaking User Stories down into tasks, which are then estimated in hours. Jeff Sutherland on the other hand suggested that some of the best teams that he has worked with burn down story points. Many agilists have expressed their view point on what they prefer and why.
According to Mike, he does not prefer using story points on sprint planning as they tend to be a long term measure which are not helpful in the short run. According to him,
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.
Tara Lee Whitaker does not agree that story points is a short term measure. According to her,
If each story is Small enough to be ‘accurately’ estimated, and Testable enough for one to create Test Confirmations then there may be little benefit achieved through breaking it down into smaller composite parts or re-estimating them in hours.
She shared a big concern about estimating the story in hours,
The main concerns I had when we initially discussed the idea of burning down in hours was that we’d not benefit from the early warning signs provided by the burndown and that we would only discover a story was taking longer than expected when it was too late.
Jim Schiel suggested that it may be possible to do sprint planning both in story points and hours. However, the return on investment by estimating in hours is not high to make that a serious candidate. According to him,
Now, let’s look at the Scrum team that commits to ten 2-story point PBIs. If they finish them all, they’ll have achieved a velocity of 20 story points that Sprint. Next Sprint, they’ll probably try 20 story points again. The Sprint after that may be a little more or a little less depending on what happens during the Sprint. This continues from Sprint to Sprint, with the team averaging a velocity that will likely be somewhere around 18 to 22.Can you do the same thing with hours? Yes, but it’ll cost you a whole lot more money to do it right. What do YOU want to pay for – completed, working software or very accurate estimates?
Jack Milunsky further reiterated the significance of story points when he mentioned the following advantages.
- Universal Measurement – Story point is a universal measurement across the team. It is not biased by the experience or skills or any individual on the team.
- Steady State – After the 3rd or 4th sprint, the team reaches a steady state and it becomes easier for the product owner to fill the backlog with the steady state story points. Nothing more, nothing less.
- In the zone – Once the team reaches steady state, business believes the technical team and this puts the team in the zone of high motivation and confidence.
Tomas Björkholm mentioned the following reasons for going the story point way.
- Reason 1. Estimation is a way of telling the size of a story, not how long it takes to implement it.
- Reason 2. Ideal man days is a size that varies over time depending on team performance. Story points are relatively constant.
- Reason 3. It's proven that relative estimation is more correct than absolute and since ideal man days is a time measure it's easy to make absolute estimations even though it could be used relatively as well.
Tomas added,
At a speech about Pomodoro Technique Staffan Nöteberg mentioned that most people feel uncomfortable about giving estimates in actual time. Aha, I thought. Uncomfortable people are less productive so estimation in days are less productive.
Mike Cohn suggested that there is no linear correlation between a story point and the number of hours. According to him, there is a distribution range for each story based on some standard deviation.
One point equals a distribution with a mean of x and some standard deviation. The same is true, of course, for two-point stories, and so on…
Hence, one cannot tell the stakeholders, given a certain velocity measured in story points, that the team would finish on a certain day. It has to be a range.
That range can a date-range such as “We can finish every item on your product backlog but it will be May or June by the time we finish.” Or it can be a scope-range, “We can finish on May 20, like you want, and we’ll get somewhere between 120 and 140 story points by then, which will be between this one and that one on the product backlog.”
Mike Cohn also suggested an alternative way, which might be in line with lean principles, called commitment-driven sprint planning. In this approach, the teams do not discuss story points or velocity. They simply take the high priority items from the backlog, task them out and estimate them in hours as per their capacity and just fulfill their commitment.
Thus, there are pros and cons of both the techniques used for sprint planning. It might just boil down to what the team is comfortable with. Which technique would you prefer and why?