Get certified - Transform your world of work today


Story Points Versus Task Hours

23 August 2012

Chia Wei Cheng
E2open Development

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

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.6 (7 ratings)


syamsundar seetepalli, CSP,CSM, 8/30/2012 12:11:52 AM
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 Savaliya, CSM, 8/30/2012 1:02:43 AM
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 -
Rick Tonoli, CSM, 9/1/2012 10:34:15 AM
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, CSP,CSM, 1/2/2013 2:18:18 AM
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.
David Meisland, CSM, 7/23/2014 4:31:28 PM
Actually I would argue that if your task hours were 9, that maybe the story points value of 5 is inaccurate. If you were in Sprint Grooming discussing the tasks (Effort) and it was 9 hours, I would have scored the story at 13
CURTIS REED, CSP,CSM,CSPO, 7/29/2015 1:23:01 PM
Cheng, I enjoyed this post.
I have often heard that points and hours are not related, it is a common refrain, but I happen to disagree with it. I accepted and believed it for a few years but the more experienced I became the more I realized it was a bit misleading.

The reason we estimate points at all is for what purpose? The team is applying a QUICK estimate of the size of each work item that the product owner wants to get done within a Sprint.
What is a sprint? It is a TIME BOX.
Therefore, we must be able to determine that the number of points we have assigned correspond generally to a story size expressed not just in "complexity" but also "duration".

If a team has 5 members, then 5*40=200 hours of available time per week, or 400 hours available.
If the team says "we can complete 50 points in a sprint", then 50 points BETTER correlate to less than 400 hours in a two-week sprint.

It is therefore, illogical and misleading to say that POINTS and HOURS are "mutually exclusive" concepts.

The elephant analogy is charming but I think it is misleading.

Why? Because we do not estimate stories to determine WEIGHT but rather to determine how many points of work can be completed within a TIMEBOX.

I would rewrite the elephant analogy by saying that a tribe must determine how many elephants they can eat in a specific period of time (2 weeks). The tribe estimates that they can eat 3 baby elephants, or one cow elephant in a two week period, but cannot eat a bull elephant within that period. Now we see that the analogy IS dependent on time.

This seems again to support your article, and my belief, that there is a general CORRELATION between point value and later the task hours.

I look forward to hearing differing opinions.
Brijesh Gopinath, CSM, 2/19/2016 12:41:25 AM
One's understanding of this post, in my opinion, is directly related to his/her understanding of what "Team's Velocity" is.

If you consider that team's velocity is a metric that the team should use as a factor to commit to a sprint, then YES there is a need to find out what a single point translates to in hours/quarter days/man days etc.

But if you consider VELOCITY as an outcome of the amount of work that the team has been churning out sprint after sprint, and its mostly only used only by the PO to adjust his/her release plan, then such a translation may not be necessary. An experienced team should be able to pull a fairly accurate number of stories (not points), to meet the available capacity, into the sprint without even looking at the story points assigned to it.

In my personal experience, at best a single point can only be compared to a range of time as the complexity of the work/skill within the team/etc, tend to change continuously in the lifespan of a backlog.
Mike Rebelo, CSM,CSPO, 5/24/2016 2:02:09 PM
Does the scrum alliance have an official point of view or definition of what is a story point?
Deepak Nayak, CSM, 1/27/2017 8:44:27 AM
Hi Chia,
I liked this post. However my confusion is why should we use both the story points and the hours together when we are basing our velocity on story points? How the estimation of tasks based on hours is helping us? And when team members are not picking up the tasks during the planning, how do we know which team member has some capacity remaining?

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up