I’m often asked about the relationship between story points and hours. People who ask are usually looking for me to say something like “one story point = 8.3 hours.” Well, that just isn’t the case (especially since I made up 8.3 hours). Let’s see what the real relationship is between a story point and hours…
Suppose for some reason you have tracked how long every one-story-point story took to develop for a given team. If you graphed that data you would have something that would look like this:
This shows that some stories took more time than others and some stories took less time, but overall the amount of time spent on your 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. Graphing that data as well, we would see something like this:
Number of hours to develop various one- and two-point stories
If the one-point stories are centered around a mean of x, ideally the two-point stories will be centered around a mean of 2x. 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.
What these two figures show us is that is 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, of course, for two-point stories, and so on…
By the way, notice that I’ve drawn the distributions of one- and two-point stories as having overlapping tails. It should be totally realistic that the biggest story that a team put “one story point” on might turn out to take more time than the smallest story they put a two on. After all, no team can estimate with perfect insight, especially at the story point level. So, while the tails of the one- and two-point distributions will overlap, it would be extraordinarily unlikely that the tails of, say, the one- and thirteen-point distributions will overlap.
Tags: agile estimation, metrics, story points
So what are you saying here ? That there is not a perfect linear relation between storypoints and time, but enough to do estimates ?
Hi Haiko–
Essentially, yes. I am also making the point that one story point may relate to a mean of let’s say 6 hours and that two-point stories may have a mean of 11 and three-point stories a mean of 19… When we look at something like the figures above, it should be apparent that plans based on those estimates cannot be perfect unless the plan is expressed using a range. That range can a date-range such as “We can finish every item on your product backlog but it will be May or June by the time we finish.” Or it can be a scope-range, “We can finish on May 20, like you want, and we’ll get somewhere between 120 and 140 story points by then, which will be between this one and that one on the product backlog.”
I hope the above data formats correctly:
Column 1 – S# – Sprint #
Column 2 – T# – Team size
Column 3 – Hrs – Hrs estimated (SBIs)
Column 4 – Pts – Story points completed (PBIs)
Column 5 – Hrs/Pts – Hours per Point calculation
As a ScrumMaster I keep PBI estimation and SBI estimation completely separate in the minds of the team members. We estimate PBIs in planning poker – story points, and separately estimate SBIs in “ideal” hours (4/day).
For my own curiosity I’ve secretly tracked hrs per point. I know they should not be considered to have a linear relationship, but I was curious if I could come up with a range of “Cost per Point”. i.e. if I know that 1 developer hour is $200, how many points per hour, and thus what’s the actual cost of a 13 point PBI.
Looking at the data it’s interesting to see how during sprints 14 to 19 we went through a big overturn in staff — a lot of people rolling off and new folks rolling on (including myself). By sprint 21 we hit our stride as a team and have consistently delivered at 1.7 hrs per point.
Am I safe to tell management that a story point costs 1.7 hrs? Or least give them a range, 1.7 to 2.5?
Mike,
Thanks for your answer. I think your second point will be interesting in the communication to a customer.
Hi Matt–
I like how you’re keeping the product backlog and sprint backlog estimate units separate. What you do is exactly the same as I do with points on the product backlog and hours on the sprint backlog.
The only real risk you have with telling management your cost is 1.7 – 2.5 hours per point (which is better than saying 1.7 or any single estimate) would be that those costs would then be applied to work estimated in larger numbers of story points. To clarify, I suspect that many of the user stories your team completed during the period above were say 1-13 story points each. You’ve probably got some larger items on the product backlog. The big project we’re hoping to get to late this year is on there are four 100-point epics. There are a few 40-point stories you’re hoping to get split up next month, etc.
Well, we don’t know how accurately those items are estimated. The 40-point story could really turn out to be a 53-point story or a 29-point story. If you look back at the graphs that started this post, my point is that we don’t know that the median for a 40-point story is 40x the median of a 1-point story. So, deriving a cost-per-story on small stories then multiplying that cost times some large units can cause some problems. I’ve done it in the past, of course, but I always want to be sure that whomever I’m telling that number understands the lack of precision in it (which is why I’d want to express it as a range).
Also, I’m worried you may be understating the cost per point. I get cost per point by figuring out the salary paid to the team over a period and dividing that by how many points were delivered. You can even ask HR to give you a multiplier to give what’s called a loaded labor cost (a programmer may get a $3k paycheck twice a month but there are also benefits, facilities costs, and other overhead). HR can tell you something like “multiply salary by 140%” suitable for your office or company. Unless those individuals were on other projects part-time, I’d want to take their full cost into consideration.
I am always concerned any time someone tries to map the relationship between story points and hours. The biggest problem I have is that once this relationship is defined, we tend to go out of our way to “prove” the relationship or change the size of each story. It doesn’t allow for the relationship to change – which is should. If a team gets faster at delivering specific types of stories the story size shouldn’t change – but the relationship between the size and duration will. Alternatively, if half a team goes out on vacation, and those that remained who worked on a 13 point story realized it took them twice as long as a 13-point story usually would. This does not mean that the story size was really twice as big as what was sized. Assuming that the story is similar in size to other 13-point stories in the backlog, then the size is still good. Because the the team’s velocity is different, the time it takes to complete the 13-point story will be different. It is still a 13-point story.
Hey Giora,
I’ve found that mapping ideal hours to story points (or ideal days) tends to be the easiest for most people. If we use something like ‘complexity’ or ‘size’, those things tend to be much harder to articulate to one another. Also, my idea of ‘complexity’ could be different from yours. Certainly this is why we discuss our estimates as a team to come up with a consensus, but consensus building tends to be easier in my experience when dealing with ideal days/hours. People can more easily wrap their head around those concepts and have similar mindsets.
I think there’s a bit of a misunderstanding with your example of the 13 point story. Are you talking about ‘ideal days’ or ‘calendar days’. I can’t quite tell if you are contrasting the first part of your post with the second.
I do see your point with the story size changing if we use time-based estimates, and if our velocity increases, we won’t necessarily be able to see that using hours/days for story points.
Brian,
I agree that working with ideal hours is easier for people to get started with – it is the same mechanism they’ve used to estimate effort for decades. Sizing in points provides a number of benefits that I know are worth the initial discomfort of learning a new sizing technique. It also gets much easier with practice. I prefer using points for many reasons though many, like you, prefer using ideal time and I certainly see not problems with that.
The part I struggle with in your comment is the mapping of ideal time to points. It is the mashing of two sizing tools that don’t need mashing. If you’re going to size you backlog in ideal days then do just that. When I see stories sized in points, I expect them to have been estimated using some type of comparative and analogous approach. If you’re applying a mapping formula to derive points from ideal days, then the relative comparison to other stories never happened.
In your response you highlighted one of the key problems when using ideal time. When we start talking about “how many hours something will take” or in my comment when I said a story “took twice as long”, it is not clear whether one means ideal time or elapsed time (for the record I meant elapsed time).
I agree with Gloria. A team can use ideal days (or other units of time), but they are really missing out on a key point of using an abstract unit like story points.
In the software world, we don’t product anything tangible per se (like a widget), but we would like an analogous unit that we can use in process measurements to provide useful quantifiable information and support process measurements.
A story point essentially represents a unit of production for an intangible entity that provides value to a customer. When we estimate, we assess the feature’s “size” if you will. It is a complex assessment with several factors to consider, but it works out, especially when those that will build it make the assessment! Granted, this system has more variability in it because creating software is a creative endeavor, but it actually works into a consistent, manageable process!
By the way, this “size” (typically story points) should not be based on time, effort, skill level, or domain knowledge. Doing so would cancel out the ability to see improvements in throughput (velocity) due to removal of impediments and waste in the system or the increase in skill level and domain knowledge of workers.
Frankly, if you explain it this way, a business person (most people) will get it and they actually like it better.
hi!. so how do we, as a new startup. give a client a Price estimate. My client wants to know how much its going to cost him in dollars? lets assume we have all/most of the stories, and some sort of point estimate etc. how do I translate that to a Fix price cost ?
Hi Bob–
The Agile Estimating and Planning book goes into this so I’d recommend picking that up. There are also PDFs on http://www.mountaingoatsoftware.com/presentations that show some examples. The one in March 2009 at the Software Development West 2009 conference should have a few slides on it.
You will need to estimate your velocity. The presentations and books cover doing this and can work reasonably well but I’d strongly suggest start collecting any data you can on team velocity. There are other blog posts on here about how you can forecast what one team might do if you know the velocity of other teams in the company, etc. The more data you collect the better off you’ll be. But you can forecast velocity in advance of having real data.
Mike, new administration in the IT shop where I work has asked us to both use agile methods and to track and report actuals versus baseline plans. If planning is more important than the plan, will I ever have a “baseline” in the traditional sense to track against? Are these activities in the same universe?
Hi Bob–
Yes, I would track against a baseline using a release burndown chart. For example, see http://www.mountaingoatsoftware.com/release-burndown. You can draw the hypothetical line showing the team’s predicted velocity and then compare progress each sprint.
Of course the estimation differs from the achieved data and both can be plotted in a frequency distribution. But this is also the case if you estimate in hours. So what is the advantage of using story points (there are advantages but I’ll get to that later)?
By the way, my guess would be that the distribution is not a normal distribution but rather a non-symmetric one, skewed to the right (maybe the reason people have a tendency to estimate to low is that they mistake the median for the average). I would be interested to see some actual distributions from real life projects!
In my opinion, the main reasons for estimating in story points are:
Estimations in hours will be interpreted by managers and customers as “real” hours. These estimations have a tendency to get a life of their own because they’re on the same scale (hours) as the achieved time. Managers will just take them and enter them in their spreadsheets. When you estimate in story points, you are forced to perform a calculation to translate them to working hours. You are more aware that they are ESTIMATIONS. Also, the team will only need to give relative estimations and be more comfortable to give a “more neutral” story point estimation.
So if I have a project…..call it X web project, and the business owners want to know how much it is going to cost to complete this. I go to my team and ask them to give me a development estimate and they say “400 story points”. I’ve never worked with them before in my life and they have no previous working history with each other ( contracted labor ) or the company I’m working at. How do I translate “400 story points” into a capital $ figure, and likewise some estimate of when the project will be completed? Do I have them do a separate estimate on hours?
Hi Chris–
No, you don’t need to have them do a separate estimate. That would pretty much defeat the purpose. Essentially you plan a sprint (which involves tasks and hours, not story points) and then infer velocity from the planned sprint. The process is fully described in my Agile Estimating and Planning book, which has a chapter dedicated to estimating velocity.
Mike,
Great article (and also interesting discussion coming back). A lot of the issues we deal with in this light are because of the traditional approach we came from. So we have a lot of pressure to equate things to hours, and track actual hours, because that is the way it was done.
I think we all know this. In working through this at my organization I have come to a points where I am working on at the moment in the transition to new thinking which I would like some ideas on.
What I’ve found is that because people think there is a normal distribution of estimates on points when mapped to hours it encourages people to think there is a relationship, one based on averages, and so the thinking goes we should use that.
Based on experience, I do not think it is normal at all. I suspect that if we graph so that 50% frequency is recorded below and 50% above, then the above would result in a long tail as that is where all the “oops” and “discovery” is.
This skews the result making the mean meaningless. I suspect this is why you talk in terms of ranges with a probability attached to them. Do you agree with this and, if yes, are you aware of any studies that would help me show this?
Hans
Hi Hans–
My experience is that people like you describe want to reduce it to something like 1 story point = 7.2 hours. They haven’t thought about it enough to realize we really should use full relationship; a mean number of hours plus/minus a standard deviation or two. When I explain it, people get it but most don’t think about it in advance. I attribute this to a human nature tendency to favor single-point estimates.
I am not aware of any research that shows whether actual duration is normally distributed or not. I’ve actually long suspected that it is a chi-square distribution, which would fit your expectation above. I haven’t yet collected enough data that I’d want to conclude which it is, though.
Hi Mike,
We have finally got into a position with a long term client where they are willing to accept the story point as a unit of measure that they wish to contract against. The contract is long (3yrs) and the projects and teams in it are diverse. We use planning poker to estimate size but with different teams.
Problem is their finance department now want to purchase a block of Story Points (yes I know nightmare). They are willing to accept that it will not be an accurate measure per se but want to know the cost of a block of points to consume. My dilemma is that the teams may have different velocities and estimations.
I was thinking of introducing a “benchmark story” into every planning session. That was universal eg creation of some global feature that all developers could associate with. Since we use Fibonacci numbers in the story we would be essentially “T shirt sizing” anyway. If I could set a value against this from historical data then maybe we could stay within some limits. Eg Benchmark Story was 13 points and would cost £5000.
Any ideas?
Hi Andy–
You should be able to look back at historical data (since it sounds like you have it) and calculate a cost per story point. Figure out how much you paid Team A over the last six months (easy for the accounting group to tell you) and then look at how many points were delivered by that team. Alternatively, see the post on here about Establishing a Common Baseline for Story Points.
[...] (given a set of user stories) or a range of stories to be delivered (given a fixed release date). Several people have written extensively on agile estimating and planning and the importance of hours and [...]
[...] “1 Story Point = 1 Ideal Day (6 hour work day)” [...]
Hi Mike,
Product Management favors the story point estimation only if they are able to commit to the customer how must will be overall the cost for this project. But currently we are not able to derive predicatable relationship out of story points. Now if you say that we take Total Story points & divide by team velocity & multiply with team rate/hr but the catch here is that all the US are not able to be estimated at the beginning itself & there are cases when story points actually gets doubled. So how do you estimate cost in such case. Can you help to provide some formula with the different variables that needs to be considered ?
Hi Sonali–
See “Agile Estimating and Planning” as that covers the whole process.
Thanks, Mike. Would appreciate if it’s possible to share brief process here. I would definitely be interested in reading in much detail but basic understanding here will help.
[...] I jeszcze na koniec odsy?am do dobrego artyku?u Mike’a Cohna na temat relacji user stories i ich faktycznego czasu wykonania: How Do Story Points Relate to Hours? [...]
Hi Mike,
Is there in any industry std used for No of Story Points per hour or day
Definitely not. They are merely a relative unit.
My question is that: Once a team decided on the story points for a given set of User stories being implemented in a sprint and then during the sprint realize that the story points were not right, do they go back and adjust the story point for those User stories ? If they do, the team velocity will also change.. So in subsequent sprint should the team revisit previous sprints and re-assign story points to completed stories to compute the actual/true Sprint velocity ?
Hi Rahul–
See my blog post on re-estimating.
-Mike
Hi all,
I thought I was the only one having major major issues with this point thing. I think I understand the story point and the relativity yet, this issue does not sit will with anyone when it comes to costs and the story point conversion with hours and hourly rate. Someone better come up with a better way to introducing story points cause to me it doesn’t work and it will not work. Hence, people are excited about Scrum methodologies but the story points are just a simple and back breaking point to the whole thing….
Hi Jaime–
Yet it does work for many, many teams.
To come up costs, look at a team over a sufficiently long period (perhaps a few months), see how much they were paid in that period, see how many points they completed, and divide. That will give you a cost per point.
Hi Mike,
Believe me, I see your point, the velocity thing and all! It’s just that upper management is somewhat interested in the velocity, but they’re more interested in what’s it costing me per point is their question!!!! I can do the same thing with hours. I make the developers break the story lines into chunkable parts that can be done in 1 to 2 days. if they get it done in 3 or 4 days then their velocity is 1/2 and the cost is twice as much. There’s no need for magic points right Mike? I just simply can’t get this point thing and I’ve been reading lots of posts out on the Web. The confusion is simply too much because all a scrum master or Project Mgr. will do is upset management, espcially if a project is going to take a long time and I’m telling about story points!! Mike, are story points a MUST in Scrum? I just don’t see the point — you know what I mean?
Mike, if you didn’t need to have points, would you use hours? Or does Scrum say, if you’re not using story points, it’s not 100% Scrum methodology? I really do like the philosophy, just not the … end with pts.
-jaime
Hi Jaime–
There are things you can do with points that you cannot do with hours (e.g., have people with different skills and experience talk to each other intelligently about the effort a story will take to complete). I won’t go into all that here because it’s covered in the Agile Estimating and Planning book, my various videos and presentations here, as well as in my course on the subject. I realize it’s not easy to convince people of the benefits of points.
But, to your real question: story points are not a mandatory part of Scrum at all. So in your case: don’t use them. All Scrum says is prioritize the product backlog and do a release burndown chart. You need some sort of size estimate to do those things, but if you like hours, use hours.
Hi Mike,
Yes, I bought your book about 3 weeks ago “Agile Estimating and Planning”. It’s a good read I like it. Page 287 in your book is what I look for when breaking down tasks into chunkable small pieces, I like that part. But I’m not convinced alot nor do I get the need to use points nor the logic to translate hours into points.
I understand that different tasks and different people have have different effort levels and different skill levels and every tasks and every sprint is different, do you see my point here? I do enjoy and appreciate the fact that you were able to discuss this point with all of us. Maybe some got, maybe alot didn’t. And it’s up to all of us to use the best method to do the best job in Project Management. This means we use all the great and good things in this methodology and leave behind what’s not understandable or easy to teach. Mike, thanks for spending a few hours here trying to clarify it to us, thanks much.
-jaime
Hi Jaime–
Yes, I understand your point. Believe me, I spend a lot of my consulting time helping people truly get to the “aha!” moment with points so that they see the benefits. In my Agile Estimating and Planning classes, that epiphany happens around midday for many people after we have a mini-debate between points and ideal days.
About a month ago I had a guy tell me at the morning break that he was completely opposed to points, didn’t like ‘em, and never would. At the end of the day he left as the biggest supporter of points because he saw how they’d address many of the estimating and planning problems he’d seen over a 20+ year career.
But–to reiterate: they are even remotely a mandatory part of Scrum. My advice is to spend the next year pretending you’ve never heard of points. Then a year from now, see if they might address some problems you’ll have seen during that period.
Mike,
Thank you so much for your reply messages. Yes, I will continue to use the great things Scrum provides and if I do end-up getting the points thing I will make sure you let you know and share that information with everyone else here on this blog. Thank you again for providing this blog service — great thinking!!
-jaime
Have a great day.
Thanks, Jaime. I’m glad you find the blog helpful. Good luck with your Scrum implementation.