So what are you saying here ? That there is not a perfect linear relation between storypoints and time, but enough to do estimates ?

S#  T#    Hrs   Pts   Hrs/Pts
14   6     219   60     3.65
  5   6     102   47     2.17
16   5.5   226   60     3.77
17   7     285   72     3.96
18   6     256   101     2.53
19   7     240   111     2.16
20   9     268   105     2.55
21   9     296   151     1.96
22   8     258   135     1.91
23   6     203   122     1.66
24   4     152     90     1.69
25   6     200   119     1.68

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?

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

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.

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.

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.

Hi Mike,
Your post really brought the hours vs story points debate into focus for me. I read this post over a year ago but recently the debate came up again. I decided to take some real numbers and see for myself what the distribution looks like. If you’re interested in my results, you can find the information here: http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html

I would appreciate any comments you might have.

Keep up the good work!

Excellent, Mike! I love seeing data like this. I collected quite a bit of this in places where I was an employee and could essentially tell my teams / ScrumMasters to collect it. I’ve had a harder getting enough clients to see the value in doing it. Data like this can be very helpful to have. Thanks for sharing yours.

I encourage everyone reading this post to check out Mike’s link above.

has anyone of you read about FPA (Function Point Analysis)? Its sad that the new age software engineering practices are reinventing the wheels. Though I am not a fan of FPA and have seen it unfit for most of the projects using new technologies, the idea behind FPA is something which is most logical when it comes to ‘sizing’ of a feature or a product - an absolute measure which can be factored into other metrics like no. of hours using company specific historic data like dev. productivity when using JAVA or .Net for a single Function Point.
I think by story point, we really are doing the same thing… trying to capture an absolute measure for a feature so that we know how big/small it is. Directly relating it to no. of hours may not be that simple equation since it depends on many factors like which technology, how productive the team is etc.

Hi Amit-
Yes, I’m very familiar with function points, including with the fact that in the 32 years since it was introduced by Albrecht it has yet to catch on in practice. I find function points a great way to calculate the size of a program *after* it has been written. But it does not work anywhere near as well in advance of writing the program. The chief problem is that if someone asks me to estimate the number of inputs a program has or how many files it will access (both inputs to function point analysis), that is no simpler than asking me “how long will it take to write this program.”

Hi Mike, I am fan of your book Agile Estimation and Planning. I do not have enough good karma of seeing in you person but I am happy to see you are responding to this topic as at May 28 2011. I live in Malaysia.

My mind is cracking under the ideas posted here and I find myself challenging personal assumptions. I have been assuming story points are pure relative size of backlog items one another. Only from a team, can we have and measure effort. Different circumstances require different effort. Storypoints which is a measure of size do not fluctuate.

Are there 2 separate principles here, one is size and the other is the effort?

Suppose a road is estimated 1 mile long. It may not be worth it but if we want exact accuracy we can measure it with long tape: say 1.2135 miles
However, the team who traverse this road may take different effort. Sometimes 20 minutes. They got thirsty, they stop by a restaurant, end up 25 minutes. Or they don’t mind sweating and sprinting, it takes 10 minutes.

Is there a 3rd principle cost, the need for a drink at restaurant, we didn’t know there is a toll gate in addition to the effort?

So if we give just story point and effort principle a relationship, wouldn’t it be velocity? Can help me check if my understanding is correct?

Hi Fun—
I’m glad you’ve enjoyed the Agile Estimating and Planning book. Thanks for letting me know and hopefully sometime we can meet in person.

To use the two industry standard terms there are really two things we are interested in: Effort and Duration. We use story points as an estimate of Effort. You are right that a “measure of size [effort] does not fluctuate.” I use the example of moving a pile of rocks from one place to another. The effort of doing that (perhaps measured as kilograms moved x the distance moved) is the same whether I do it or my young daughter does it. 

What changes will be duration—if I do it the duration will be shorter than if my young daughter does it. The easiest way to think of calculating duration is as Effort (in Story Points) divided by Velocity (in Story Points). If we think of teams of one person, my velocity will be higher than my daughters so my duration is shorter.

So, I think the points you are making are valid except I’d change “effort” in a few of your sentences to be duration. Think of duration as the amount of time elapsed on a clock or calendar. Your team on the road example fits when about duration.

Did you know your book Agile Estimating and Planning is number 1:
http://www.noop.nl/2010/08/top-100-agile-books.html
When will we see Part 2?  :)

I love your other analogy on complexity. Licking 1000+ stamps and brain surgery may have same story points or effort but can we see the contrast in complexity?

While I like to describe points as size, I need to think in industry standard terms. I should use Effort and Duration.

Hi Fun—
Yes, I’d seen that Agile Estimating and Planning did well in that book survey. I’m quite proud (still) of that book.

As you may have seen, there is a lot of discussion in the comments of “It’s Effort, Not Complexity” about the fact that complexity can influence the estimate but only to the extent the complexity influences the effort involved.

Thx for this article, it`s going to help me a lot. I have to explain to the business the relation between points and time, because they some times thing that those are the same.

Thanks a lot!

Hi Carolina—
I’m glad you found this post helpful. Thanks for letting me know.

Really useful, I am trying to convince my team points and time are different.

Well, I’m none the wiser! When estimating the number of story points in a task, what do people do? Try and guess how many days the task will take, presumably, since duration is what matters when fitting things into an available duration. Then, when estimating how many hours it’ll take, they have to have a notion of story-points per hour.

In fact they needed that notional value when guessing the story point figure.

Seems like there’s a lot of tap-dancing around to avoid reality?

Hi Anonymous Commenter—
Teams don’t estimate the number of story points in a task. They estimate story points in a story (or any product backlog item).

Sorry, when I said task, I meant PBI. Didn’t know task was a term used in Agile for something else.

I have a question on the story point accuracy. In our group I see that we have 1 SP stories which map to a wide range of hours, for example, 1 hour all the way up to 100 hours even. The overlaps between point is large as well. For example, 5 SP might equate to 15 to 110 hours.

How can SP accuracy be properly acertained, if SP are not tied to unit of time? Can i say that 1 SP means work to be completed within 1 - 10 hours, 2 SP means 10 -20 and have people make estimated based on that?

Hi AgileBeginner—

Who said points are not tied to a unit of time? I very much believe that story points are about time. If not, what else could they be about? Time is what our customers care about when they ask for an estimate.

You are going to need to help your team get better at estimating if they are off as dramatically as you’ve listed. I think the idea you have at the end of 1 being about 1-10 hours and two being about 10-20 hours is in the right direction. And you may need to be that clear with your team right off. The challenge then will be that you will want to switch the conversation so that all estimating is done relatively. You want to be asking, “So, team, you’re saying this story is about the same effort as that story?” That’s a better question than “how many hours is this” because your hours are not my hours (we work at different rates). So, start with definitions like you have above if you must but soon try to change the discussion to be purely relative. There’s a lot more on that in my video course on agile estimating and planning.

Hi Mike,

I have just started reading various concepts and terminology with respect to Agile.

As I understand, the term velocity means no. of backlog items completed in a particular sprint…However, these backlog items may be different in terms of their sizes.

So will it not be a good idea instead to consider no. of story points completed in a sprint as a measure?

But then another aspect as I understand is that story points are relative to each other in a particular sprint. So probably a backlog item equivalent of 1 story point in a particular sprint may not necessarily require the same amount of effort for the same developer for another backlog item equivalent of 1 story point in another sprint. Can you please help me to get some clarity here?

Hi Amit—
I’m glad you’ve become interested in agile and are reading about it.

Velocity refers to the number of story points completed, not the number of items completed.

Story points are indeed relative to one another but that relationship should go beyond a single sprint. That is something we call 5 points this sprint should take about the same amount of time to develop as something called 5 points in a different sprint. We do not start over each sprint with different meanings to our point values.

Hi Mike,

Thank you the prompt response. Really appreciate it. Yes, it does help me now to understand what it means when you say the story points are relative. So essentially you would have certain benchmark to qualify as 1 story point which would be common across all sprints.

Regards,
Amit

Hi Amit—
Yes, a 1-point story would be the same across all sprints. And each 1-pointer should be about half of each 2-pointer.

In order to work out how long a project will take (unless you have an unlimited budget, which is rare these days) I believe you need an initial “exchange rate” for story points to days, e.g 1 story point = half a day.  And then once the project commences, you drop the association and just deal with story points alone.

Hi Murray—
That relationship is called velocity—the number of points a team completes per sprint. If a team has been around for a few sprints we’ll have historical data on their velocity and can use it to predict the finish date. If a team hasn’t yet worked together for even a couple of sprints, it’s necessary to forecast velocity. I cover that in the Agile Estimating and Planning book and in the online video course. It’s on my list to create a blog about it, too.

I still didn’t get it that how to calculate story points.

Can someone just explain in simple words that how to estimate hours.

For Example if the story points are 3, 4, 5 then what is the current process of calculating hours.

Would be good if we write it like this.

Step 1
Step 2
Step 3
So on…

Thanks
Raj

Rajj—
We don’t directly calculate hours from story points. Story points are used for determining high-level plans typically covering something like 3-6 months of work. Hours are used in sprint planning, looking ahead 1-4 weeks. Certainly there’s a correlation—-both are measuring time—-but that correlation is indirect and not particularly useful to know.

Imagine you are in charge of designing a huge city—you’re going to lay out everything in that city such as its roads, hospitals, etc. but also design every house in the city. You’d start out working at a high level. Let’s put a hospital here, a shopping center here, a market there, some homes over there, roads here and there. Etc. This plan would be drawn out on some paper with a scale of something like 100 meters per square. Eventually you’re going to have to design each building. To do that you’d use paper with a much smaller scale (1 meter per square). That’s what agile teams do with separating high level “release planning” (or “long term planning”) from sprint planning.

In my example there is of course a direct correlation between 100 meters per square and 1 meter per square but I could have made that more obscure by saying “a quarter-mile per square” for the high level planning. Yes, there’s a relationship but it’s not one we need to be aware of. Plan the next six months with points and velocity. Plan the next 2 weeks by identifying tasks and hours.

I am sorry mike but still that doesn’t answer my question.

All i need to know is how to calculate number of hours for any task from product backlog.

Rajj-

I think the purpose in each of the cases is different. In high level planning (Release Planing)you have horse before the cart, rightly; and one should not do the opposite of it when doing Sprint Planning. In the later case, the team should take each PBI and break it up into tasks and do the estimation for hours. In the former case(Story Pointing), one can identify the benchmark story via Planning Poker sessions and do the estimation and allocate some SPs to this. Later, all other Stories can be estimated in relation to this benchmark. Also, the benchmark story may not necessarily be the smallest duration story. Now, my question is how do we choose benchmark story - should we choose the story for which we have complete knolwedge and there are no unknowns, or the a mix of knowns and unknowns.

Hi Sanjiv—

My recommendation is to avoid picking a single benchmark story—a “gold standard,” if you will. Instead start by finding a 2. That’s something small but not the smallest. Be familiar with the type of work on the product backlog and that the team does and pick a story that is a typical small story for that team and call it a 2. Then look for something to call a 5. Maybe you don’t find a 2 and a 5, you find a 2 and an 8 or a 3 and an 8. But those two numbers get us started.

From there I recommend playing Planning Poker. While playing Planning Poker, the team should do a lot of triangulating: “So, if we call this one an 8, we’re saying it’s the same size as Story P and smaller than Story Q. Does that sound right?”

Thanks Mike!

Surely, that will help.
Further, I would request your opinion on the point that I raised above on known/unknown.

Hi Sanjiv—
I already addressed that by saying I wouldn’t ever have a single benchmark story. Any new story can be compared against any old story (and should be compared against multiple when being estimated, which is called “triangulating”).