Story Points Versus Task Hours

"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.

http://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours