Story Points Versus Task Hours

August 23, 2012 in Basics

"Cheng, this is just a three-point story. We shouldn't take more than 30 hours to do this," one of the developers told me during the sprint planning.

And a development manager once advised me, "Cheng, you must not pull in any other stories, because we already committed 30 points' worth of stories and our velocity is just 28 story points!"

"But we still have capacity, and one of our developers has only committed 50 percent of his time for this sprint. Furthermore, the team does really want to commit another story," I replied.

"So what? That's the rule. We cannot commit more than our velocity!" the manager said.

These are common controversies about story points and task hours. Sprint planning can easily fall into hours and hours of argument with some "should" or "must" that doesn't make sense — but that I just can't find any facts or points to persuasively deny.

Then I recall a lesson in a CSM training that I attended recently. Jesse Fewell, the trainer, told me story points and task hour comparison can be thought of as the comparison of the weight and height of an elephant. In general, a taller elephant may be heavier than a shorter one, but this is not always the case. There is no biological proof of a weight-versus-height formula, despite the common perception that more height means more weight. The same explanation applies to story points versus task hours: In general, a more complex user story (higher points) should take more hours to complete, but there are always exceptions.

For me, story point is high-level estimation of complexity made before sprint planning. It could be done during release planning, but I think most Scrum teams do it during a preplanning session. Story points and sprint velocity then give us a guideline about the stories to be committed in the coming sprints.

The task-hour estimation, on the other hand, is a low-level estimation made to represent the actual effort in hours needed to accomplish all the requirements of a story. Such an estimation should be done during sprint planning for highest possible accuracy, as the actual development may start the next day.

Given the fact that story points and task hours serve different purposes at different times, forcing a relation between them may not be advisable. As the diagram below illustrates, I recommend not considering the story points too much during sprint planning and just estimating the time needed to accomplish all tasks required to complete the user story accurately.

Share on Facebook Share on LinkedIn Share on Twitter

Article Comments

syamsundar seetepalli said on 30 Aug 12 00:11:

Hi Cheng, I completely agree with your view. I would like also to add that it 'may' not be practically possible to estimate upfront all the tasks required to complete a user story. So, In some cases, when new tasks are created(which were not identified during sprint planning for whatever reasons) during the actual sprint to realize the user story, I have experienced the complexity of the user story changing for ex:- medium to high and presented its own challenges to deal with =:)
Sikunj N. Savaliya said on 30 Aug 12 01:02:

I understand that the best practice is not to relate them but in case you have to have a high level sense for the same here is the link I would like to refer - http://michaellant.com/2010/07/05/estimating-effort-for-your-agile-stories-2/
Rick Tonoli said on 01 Sep 12 10:34:

We've found what we think is a good use for junction between story points and task hours. When we plan we use the task hours as a kind of "check sum" for the story points to point out inconsistencies. For example if you have a low point story, but it has days of tasks, that tends to point to a problem with story point estimation and should trigger a re-vote on it's value. Also we've found from the months of data we have that stories of similar value tend to have similar hours (I did not expect this), however because this is was not true in some cases, we tend not to use it as a rule of thumb.
Srinath Chandrasekharan said on 02 Jan 13 02:18:

Hi Cheng, while what you have said is true for a team starting on Scrum, if the same team is working on the project for a some time (5 -6 sprints) , I would expect that there is some relation between the SP and the effort spent in the sprint. So for example if after 10 sprints, the team is delivering 20 SP for 200 hrs of effort and the same team continues to work, then maybe in the later sprints I would expect the same team to deliver more than 20 SP's for the 200 hrs of effort. So one can use this as a measure of productivity.