Get certified - Transform your world of work today


How Many Hours Is a Story Point Worth?

One of the concepts new Scrum teams struggle with is how to relate story points and hours. People want an easy answer, such as “one story point = 8.3 hours.” The truth is, though, that the relationship, while real, is not quite that easy to quantify and will vary greatly from team to team.

Suppose for some reason you track how long every one-story-point story takes a given team to develop. If you did, you’d likely notice that while the elapsed time to complete each story varied, the amount of time spent on one-point stories takes on the shape of the familiar normal distribution.

Now suppose you had also tracked the amount of time spent on two-point user stories. Ideally the two-point stories would be two times the mean time of a one-point story, and will follow a similar distribution curve as shown in this image.

This will never be exactly the case, of course, but a team that does a good job of estimating will be sufficiently close for reliable plans to be made from their estimates.

The relationship between points and hours is a distribution. One point equals a distribution with a mean of x and some standard deviation. The same is true, as well, for two-point stories, and so on. While there might be some overlap in elapsed time between 1 and 2 point stories (some one-point stories might turn out to be bigger than the team thought; some two-point stories end up being smaller), or between 2 and 3-point stories, there will rarely be any overlap between a 1-point story and, say, a 13-point story in terms of actual elapsed time.

With all that being said, I caution you against formally relating points to hours. You run the risk of forgetting that each team’s mean time to completion will be as different as their idea of what constitutes a point. Points are, after all, a relative measure.

Do you want one short tip each week from Mike to help you succeed with agile?


Article Rating

Current rating: 3.8 (33 ratings)
Pallav Sheth
I am reading that article again to share the same with my new team. Your explanation helps a lot.
9/13/2017 5:03:58 AM

besi h beam murah
ayo belanja di tempat kami dijamin beruntung
10/3/2016 12:29:07 AM

Just add 5 star rating. You discuss details and well explain too.
It's true 5 point story only took 8 actual hours for me.
9/24/2016 11:06:22 PM

Mike Cohn
Hi JP--
I absolutely think there's value in measuring this. But the problem is that doing so often introduces dysfunctionalities into the team--e.g., team members start padding their estimates so their actuals don't go over. It's those problems that make me less inclined to gather this data.
8/30/2016 10:54:48 PM

I think calculating the mean and deviation of the storypoints for a team can be somewhat useful for determining if a new team needs help with how they are estimating their storypoints.

For example, if a team has some 1 point user stories which sometimes have the same number of hours as some of their 13 point user stories, the team may not have a good sense of their baseline user story or they may not be grooming their stories deep enough. An issue like this is probably an indication of a deeper problem which will require some additional investigation to uncover.

So, while I agree with the author that using SPs to calculate how long something will take to complete probably isn't a good idea, I do think there can be some value of calculating mean and deviation for other purposes.
8/30/2016 3:44:28 PM

I think even the most experienced team Ive known went for a couple years using story points for PBI's and hours for tasks.
Eventually everyone got tired of measuring hours for tasks, so now they just track tasks without putting hourly estimates on them. Tasks are just for the team to track their own work during the Sprint/

Also, I don’t think “action task” is a standard Scrum term, but we do expect teams to come up with their own implementations so maybe it’s useful for some.
8/26/2016 10:11:37 PM

In my opinion it gives a lot of pressure to developers. It will compromise the quality of the product....What are we aiming for Quantity or Quality..?
Just sayin...
7/25/2016 9:24:26 AM

Mike Cohn
Thanks, Tarang.

I'm not familiar with any studies that have been done to test the type of distribution. But you are correct, it would not in reality be a normal distribution. (It's just easier to start there as it's what most people are familiar with. If I draw something different, I have to explain why and then the discussion shifts to the shape rather than the idea that there not an equivalence between points and hours.)

A starting assumption would be that the hours form a beta distribution as at
11/2/2014 9:21:06 PM

Mike Cohn
Thanks, Hemant. I'm glad you enjoyed the post.

I would not re-estimate that user story in the situation you describe. I guarantee you have other stories estimated at 2 in your product backlog and some of those will also turn out to be 5-pointers. But you won't know that until you do them.

So if you re-estimate the current 2 to be 5, you will overstate velocity. That will feel good today when you can report a higher velocity. But it won't feel good when someone divides by velocity to get a predicted completion date.
11/2/2014 5:54:52 PM

Tarang Patel
Mike its a nice article. Though what may be lost is that its a hypothesis that for a given team there is Gaussian distribution between Story Points and Time estimates. I wonder if anyone got a chance to test this hypothesis? Isn't it likely that a team, based on how stable it is and how stable their work environment is, may well have any other distribution then say Gaussian?

Also once an empirical mapping is performed with the teams data isn't that in itself likely to act as an anchor to future estimates that the same team makes.

I imagine many teams have a desire to have a map between story points and time, and the easiest thing most teams will do is create a linear map, which isn't the case as I think you point out. I fear some some team environments may well lead them to see every problem in their development as a nail that is to be hammered down by such a mapping.
10/27/2014 2:03:23 PM

Hemant Kothiyal
Nice article Mike. I have question from my persional experience. In my project one of my team member asked me to increase the story point from 2 to 5 in the middle of the sprint because he realised that his initial story point given (considering complexity and risk) does not justify now as during development he found this story more complex. How should we handle such situation?
10/10/2014 10:40:20 AM

Mike Cohn
Hi Susan--

I'm glad you've been successful with points.

Convincing people to try story points is hard. They are a very foreign concept. I feel like my life is devoted to lobbying on their behalf and it can be hard. Here are a couple of things I do:

a) Make a list of 8 dogs. Ask the manager to estimate with you how long it will take to groom the 8 dogs. The manager won't want to because he or she doesn't know much about dog grooming. Clarify that isn't the point and that taking a reasonable guess is fine. Have a few pictures handy. As soon as the manager says "that fluffy poodle with the French cut will take 2 hours," you say, "I should have mentioned I'm an expert groomer--put myself through college dog grooming in fact--and I know that cut would take me 2 hours and would take you much longer since you're inexperienced." The point is you are (at least in pretend) a great groomer. Your manager isn't. As soon as the manager agrees it will take you 2 and him 8, ask how you can now solve that problem. You are both right--you 2, him(her) 8. The manager may say to go with your number since it's the lowest. OK, onto the next dog. You're still the expert. We can't put your number on everything--you can't do all the grooming as that isn't realistic.

Now offer to repeat it with points. See if he can agree that perhaps this labrador really only needs a shampoo--so let's call that a 2. (In case we have a small, shampoo-only dog to call a 1.) You can he can agree on that. Then get him to agree that the poodle is say 5 times more time to cut. So call it a 10. And so on. That is, point out the intractable problem that your time and his time are not the same. Yet you can agree on a more abstract value: points.

Point out that dollars are a similarly abstract unit and the whole company (if in the US) runs on dollars. (Miles are another abstract unit.)

b) Live with it but constantly ask relative questions. That is ask "how big is this compared to that" rather than "how long will that take?" That effectively gets you the benefit of story points even if they are called something else.

(Sorry for the long reply and for the slow reply. The slowness is because I knew I'd write a long reply!)
10/1/2014 9:59:50 PM

Susan Thompson
I've had great success using story points correctly. I continue to struggle with some development manager who insist that hours must be weighted heaviest in estimations. How can I get them past this if they won't even try the concept?
9/27/2014 1:42:44 PM

Mike Cohn
Hi Jeewan--

Yes, I'd agree with you, especially that the key is in using story points properly.
9/22/2014 8:45:40 AM

Jeewan Chandra Bhatt
Hi Mike,

I would add that using story points is great and is a great way of estimation if used properly
1. Is based on size, complexity and Risk
2 Brings out discussion in team and many hidden issue can be unearthed, I have seen cross functional team using it very effectively
3. Should not be equated with time, instead should be used to see how many story points can be delivered per sprint/Iteration
Yes, at start it may not give clear picture but with time it gives very clear picture of progress
4. Is very team specific, if team is changed, I think its better to have new story points

It’s difficult to convince stakeholders about story points, but this is the fun part :-)

Also conducting an effective planning poker session is one of the great arts which Agile provides
9/13/2014 12:49:25 PM

Mike Cohn
Thanks, Ajay.

I think the best way is with story points. To learn everything about points, estimating and planning, I recommend my video course at
9/5/2014 8:46:23 PM

Goof mind opening thoughts by Mike
What is the based way to estimate the efforts for project.
9/5/2014 3:30:54 AM

Nick Coster
I just want to re-iterate Mike Rucker's comment about the reason for asking the question in the first place. The experience that I have had is that the part of the business (ie Product Management) that is requesting the feature or functionality to be built needs to know both a delivery time and an estimated cost to deliver.

The use of story points and velocity obfuscates this information, particularly given that when the information is needed needed the team velocity is unknown.

My approach has been to consider the loaded cost of a known sprint (from previous experiences) as this generally have more fixed elements than the the variability of a given story point or velocity conversion. In collaboration with the development team the Product Manager, Product Owner, Scrum Master and the rest of the Scum team estimate the rough number of sprints required for a minimal marketable product to be releasable. This require a reasonably clear understanding of the high level (Epic) requirements to be delivered.

The outcome of this is that the Product Manager can get the funding approved and development can start. Once dev starts then a careful watch should be applied to the actual team velocity to ensure that the high level estimates are not too far off. If they are then we call it out the the Product Manager as early as possible.
8/26/2014 9:22:07 AM

@Dan - Agreed.

@Thomas. I absolutely agree. I have to continually stress to people exactly what you said that story points are a proxy for time. I blogged on this and stirred up a log of dissent with people insisting points should be estimates purely of complexity. See

And yes also to your point amount minimizing the standard deviation. I use the example of security at the airport. What kills me as a traveler is never knowing--will I get through security in 5 minutes as happened yesterday or will it take 90 minutes as it does occasionally?

@Don: I absolutely agree from teams getting into a discussion of points=hours. It is very possible after the fact to determine how many hours a point equals on average but that is very different from a team just deciding "1 point = 1 day" as teams will. That's not the result I want from this post. The big problem there is that team members work at different rates so we can't say 1 point = 1 day for everyone on the team.

@George: What I do in that situation is make the first few arguments that they should shift from that mindset. Then the key is always asking relative questions while estimating. In Planning Poker, ask "What story is this one like?" And, "OK, if this is an 8, that means it's like this other and about twice as big as this one?" Keep the discussion relative and never ask "how long will this take?"

@Deris: My standard recommendation is to do exactly as you describe (points for stories; hours for tasks). But I've also worked with plenty of teams that get to a point where they feel they can stop doing the hours. I teach that the hours aren't all that important--they're just a tool for deciding if the team has pulled the right amount into a sprint. Teams need to do that for awhile but afterwards can if they want stop putting hours on tasks. My preference, however, is to continue with hours but use ways to make putting the hours on there take essentially no time at all. I focus on coaching teams to do that rather than to abandon them. And, I'm not familiar with "action task" so that is definitely a non-standard Scrum term.
7/28/2014 7:46:14 AM

I think even the most experienced team Ive known went for a couple years using story points for PBI's and hours for tasks.
Eventually everyone got tired of measuring hours for tasks, so now they just track tasks without putting hourly estimates on them. Tasks are just for the team to track their own work during the Sprint/

Also, I don’t think “action task” is a standard Scrum term, but we do expect teams to come up with their own implementations so maybe it’s useful for some.
7/28/2014 6:46:34 AM

George O'Grady
I inherited teams (3 of them) that like to equate SPs to Hours. But, now the teams have been shuffled and I inherited a new team. Trying to break the story points from task to relative is one tough habit to break. Getting there with those gentle reminders and starting off with the t-shirt sizing. Anybody have the same issues and hints to help me refocus the team would be appreciated!

7/18/2014 10:13:59 AM

Don Cahala
I am still an advocate of Planning Poker. It gets people thinking as to size, complexity and brings the group together as to what a point means in effort. Stay away from Hours=points if any way possible. Also use sticky notes to form a Hierarchy of which story has more weight over the next. It is a bit of a learning curve, but over time the points will become more consistent. DON'T cheese out on changing the value of your points to fit an iteration. If it fails, you learn, the group learns. It is cooperative and should be transparent.
7/18/2014 8:35:52 AM

Thomas Bellinson
Every time I read or have one of these discussions about story points, I am reminded that as a development team, we are faced with a simple formula: work effort + time = product. These two variables converge to determine a team's productivity level. Story points are ultimately just a proxy for time.

Every team I've worked with has tried to create consistency between points and the time they represent. Good teams keep the standard deviation of time:points low and their output becomes more predictable.

Isn't that the goal? We're trying to establish a predictable velocity. If story points help us do that, they are a useful tool. If not, the team should try something else.

One of our teams abandoned story points altogether. They try to make all the stories roughly the same size and they count them. I say -- do whatever works for the team.
7/18/2014 6:52:39 AM

Dan Rawsthorne
Interesting blog, but the curve isn't going to be a normal distribution. What you'll find is that it's a Beta distribution, which is how time per unit stuff distributes.
7/18/2014 3:30:16 AM

Mike Cohn
Thanks, Jai.

That's a great summary you provided of the benefits of estimating product backlog items with story points. Thanks.
7/13/2014 12:44:02 PM

Jai Singhal
Great post Mike!
I can think of following related ideas:
1. Relative estimation provides quick way to estimate with consistency. Triangulation allows placing the story in relationship to the other stories.
2. Planning poker also allows the team to reach consensus on story size. However, to get the stories, a relative term or stories of relative sizes must be distinguished for planning poker to be really effective.
3. In addition, when relating to hours, there needs to be distinction between ideal-hour vs. actual hour.
4. Besides, estimation is done relative to other stories for another reason that each team member may have different performance level. A developer could develop a story in one day while another developer takes three days for the same story. This could inherently distort estimation.
7/11/2014 11:00:23 PM

Mike Cohn
Hi Guy-

Yes, one advantage to story points is that they can abstract team members away from discussions about time. That doesn't mean, however, that we as ScrumMasters, Scrum experts, consultants, coaches, etc. shouldn't understand the relationship. The point of this post was to get people to stop thinking "1 point = 8.3 hours" (or whatever number) and instead think something like "1 point equals x hours with a standard deviation of s."

Hi Mike--

I will never fault a businessperson from wanting to know more than just the number of points in a project. Telling a businessperson that a project will be done in 100 points is meaningless--unless it is accompanied by a velocity expectation. Story points are a great approach to estimating work. They are not always the best way to communicate about the work. (With some customers points work great!) The easiest way to communicate with someone who wants to know cost is to speak of the cost per sprint--100 points with a velocity of 20 will take 5 sprints and our teams costs $15,000 per sprint. Or calculate a dollar cost per point. To do that look at how much was paid to the team in the last few months and divide by the number of points delivered.

Hi Kimberly--

Congratulations on making the move to Scrum. I hope you and your team like it (once you get used to it--it's pretty weird at first). I don't recommend planning a sprint with points. Points are great long-term predictors (where will be in 3 months?) but I recommend planning a sprint in what is known as "commitment driven sprint planning" or sometimes called "capacity driven sprint planning." Basically, ignore the points and grab product backlog items one at time, breaking each into tasks and estimating the tasks until the sprint feels full. Plus, nearly all Scrum teams overcommit in their first few sprints so your team will likely learn to adjust from that common problem.
7/8/2014 8:04:12 PM

Kimberly Chan
Good point here. My company just recently moved to Scrum project management from the Waterfalls project management system. Well, the team is struggling with the points system and this often leads to poorly quoted sprints.
6/30/2014 12:19:58 AM

Mike Rucker
My experience isn't that teams want to equate points to hours. Rather, it's that the person who obtained the funds for the project wants to be able to equate things to dollars. And the simplest "currency" that the people to the left of the PO know is hours. Our challenge is, in light of your article, two-fold: (1) resist any request or temptation to try to equate points with another "currency"; (2) educate customers, stakeholders, and she-who-holds-the-checkbook on the irrationality of being able to estimate anything other than as a relative comparison.
6/28/2014 5:00:49 PM

Guy Strelitz
Hi Mike

My understanding of the value of story points is that they free us from well-studied cognitive biases in time-based estimation. So calculating the relationship between points and hours is not just inaccurate and approximate - it's dangerous! It invites the team to start thinking in terms of hours and converting to points, instead of comparing tasks and filling the sprint based on yesterday's weather.

6/27/2014 9:28:30 AM

Mike Cohn
Hi David--
The only thing I'm aware that has been published is on my blog: I've got similar data from a handful of clients who shared this.

Hi Lisa--
Great idea to do that. We should always try to learn from an estimate that turned out to be way off. Sometimes we can discern patterns such as that a team always underestimates certain activities. Other times, it's just a random mistake.

Hi Stefano--
That is a great way of thinking about this. I hope you don't mind if I try it out in some classes! I've usually used any national currency--dollars, pounds, Euro, kroner, etc. I hold one up (say $20) and ask what it's worth. I make the point that $20 is worth four $5 bills. Or worth 3-4 Starbucks coffees, etc. It's worth what we can exchange it for.

Hi Stanley--
You're right. If you look at which is data from one client, you'll see this. Look at the median actual hours. One point was 21 hours. Two points is 52. If the 21 were perfect, two points should be 42. (So maybe the "right" numbers are 26 and 52, but maybe they're 21 and 42. We'd need to do linear regression to be sure, but let's stick with 21 as the "right" number for 1 point.) That means 3-point stories will be 63 hours. Wow--they are 64 in this example. Awfully darn close. Five point stories should be 105. Wow, they're 100. This is working. Notice then it drifts off with 8 points. In part that's because I coach teams to use the numbers as buckets--the 8 point bucket holds things too big for the 5-point bucket; so 6, 7 and 8 point stories. So presumably 7 is the average size in the 8-point bucket. The estimates, though, are still drifting from our predicted 7x21 here. The graph ends with 8-point stories because 13-pointers were too big for this team to directly bring into a sprint. A 13 was broken into multiple smaller stories first.

Hi Saravana--
Thanks. I like how you explain that to people. The relationship between points and hours is a relationship--not an equivalence. It's not 1 point = 8.3 hours. It might be 1 point = 11.2 hours with a standard deviation of such-and-such. But, it's not exact.
6/26/2014 9:35:25 AM

David Grant
Thanks Mike.

Are there are any papers which you know of that contain raw data to provide evidence for Story Point estimates being normally distributed?
6/26/2014 2:30:43 AM

Lisa Owens
Good points Mike. Every once in awhile, especially when really obvious, I would ask the team why a 5 point story only took say 8 actual hours and in the same sprint a 2 point story took 25 hours. Answers varied and I wasn't asking to place blame or praise. Just curious so we could estimate better. I found over time, it always balances out.
6/25/2014 11:25:19 PM

Stefano Bertacchi
The more I think about points the more this reminds me of those resorts that give you little marbles to buy drinks in the resort rather than using actual currency.
You end-up spending your marbles focusing uniquely on how many you have left rather than going off on comparing drink costs with your bar at home or your hourly wage or what you could rather have for the same money. Your experience is simple and distraction-free: "I have enough marbles for 5 drinks, do I want one now? yes/no."

Quantization (points) frees estimates from the distraction of committing to an absolute amount of time and forces your analysis to be a comparison between the story you¹re estimating and previous ones of known "weight" rather than going off thinking about your manager expectations, distance to release date, John's party on Friday, etc.

Worked for me to make peace with points :-)
6/25/2014 4:52:52 PM

Stanley Kurdziel
Based on the principle of larger estimates representing less well known work, I bet that if one did plot these graphs, that higher numbers would be much wider and less well distributed than the lower point estimates. I also bet that the number of hours spent would not be liner with the number of story points. Ex: on average an 8 point story is likely to take more than 8 times longer than a 1 point story.
6/25/2014 4:24:24 PM

Saravana Bharathi
Good Post Mike. I always try to tell the team not to scratch their head to find relationship between Story Points & Hours. It is never going to be accurate, and sets unwanted expectations in-front of management. Above post summarizes well. Next time if someone asks me i can point them towards this post :)
6/25/2014 2:47:50 PM

To leave a comment, please login with your credentials.


Newsletter Sign-Up