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)
Comments
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

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.

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



 Security code