# How Many Hours Is a Story Point Worth?

25 June 2014

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.

### Article Rating

Current rating: 4 (6 ratings)
 Mi @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 http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity 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

 Deris 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!george 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

 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 MikeMy 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.Guy 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: http://www.mountaingoatsoftware.com/blog/seeing-how-well-a-teams-story-points-align-from-one-to-eight 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 http://www.mountaingoatsoftware.com/blog/seeing-how-well-a-teams-story-points-align-from-one-to-eight 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

 Leave comment