Why use story points instead of hours for estimating?

After using hours to estimate our projects for a long time and rarely coming within 20% of actual "work-to-ship," I have been told by a handful of people that "points" work a lot better at gauging the complexity and estimated length of tasks within a project.

How are story points better at estimating the work required for a project?

-
"rarely coming within 20%" this means there's a fundamental break down your project plans. Moving to story points is not going to even remotely address this, you're just going to obscure your underlying faults. – Chris Marisic Apr 2 '14 at 18:37

Using points is one version of what is often called "Relative sizing." For a very highly recommended initial perspective, check out this video and then come back. Most uses of story point estimation limit you to the lower end of the Fibonacci series: 1, 2, 3, 5, 8, 13 because the goal is to group things of similar overall size rather than to pursue a highly precise estimate.

Story points often take into account three different aspects when estimating: Complexity, Effort, and Doubt. This allows them to more effectively capture the sources of variation that will make an hour-based estimate wrong.

Complexity is the "stuff we have to figure out." We know we can solve the problem, and we probably have a decent feel for how we'll approach it, but we still have to figure it out.

Effort is the sheer amount of stuff that needs done. For me, that example is configuring SharePoint lists, because I knew exactly how to solve everything, and I knew how many there were, but it still took time to run through them.

Doubt is about the stuff we don't actually know if it can be done. We may suspect we're on the wrong track, that the technology isn't up to it, or some other factor that would cause us to churn for a while before we figure out if we can actually do the work.

Most stories contain a combination of all three, and thus it's useful to have a common language so that when I say "it's an eight", I can follow with "because of the complexity of the foobar algorithm" or "because I'm not sure if our cache is set up to handle that yet."

The final point estimate is just a way to say "taking all of these things into account, I think this is bigger than most of the things we've called a three and smaller than most of the things that we've called an eight, so it must be a five"

-
I totally agree. Also, when estimating in hours there usually forms some sort of psychological barrier of extending the task longer than estimate (which affects quality and refactoring capabilities). Something analogical happens with tasks that team could finish earlier - there forms a psychological permission to take free time instead of shortening the task estimation. (which affects productivity) – Bartosz Rakowski Jul 20 '11 at 8:27
If it's "relative" sizing, then why pick arbitrary labels like 1,2,3,5,8,13...? Why not just 1,2,3,4.. or even A,B,C,D to indicate that they are not quantitative measures? – mehaase Nov 28 '12 at 21:59
A quantitative measure is useful when it comes to estimating 'velocity' of a team. If a team completes 30 relative points each week on average over the last 3 weeks, you can then use the remaining points to estimate a completion date. – Charlie Brown Dec 3 '12 at 18:18
@mehaase, We prefer an exponentially increasing series in order to drive home the bigger gaps as items get larger. After all, the difference between a "1" and a "2" is much more important than the difference between "13" and "14". – Eric Willeke Jan 24 '13 at 20:32
@mehaase, It is easier to distinguish 8 and 13 then 10 and 11 since difference between 10 and 11 is to small (10% only). For example, the difference between 1 and 2 is 100%, between 2 and 3 is 50%, between 3 and 5 is 66% ... between 8 and 13 is 62.5%. – Ilya Palkin Apr 6 '14 at 19:09

I wouldn't say the points are better. This is a technique focused on a different aspect of estimation. It may turn out that your point estimation will suck more. Have that in mind.

1. When estimating in hours you focus on answering the question "How long it may take us?". So basically it's more or less guessing, based on your previous experience.

2. When estimating in points you focus on relative sizes or complexity of estimated tasks/stories/whatever. So you usually take some of your tasks and apply one of the point values to them, and later, for each other task, you try to answer the question "How big is it in relation to those I've already estimated".

The key thing about points estimation is that you need to actually measure how the estimates relate to time. After some initial time in the project (especially when you start with point estimations) you learn how many points you are able to deliver in each iteration or fixed period of time. This gives you the basis for planning the future releases.

If you will search this forum you will also find at least a few methods of estimating in points. Try it and see for yourself if it gets more accurate for you.

-
"estimates relate to time." so both are merely guesses and there is no difference except you're adding an abstraction to time. Businesses deal in time, not effort. No one cares about effort. This isn't elementary school you don't get participation awards, business is about results. – Chris Marisic Apr 2 '14 at 13:31
@ChrisMarisic velocity is for translating points into duration. Even if the estimate is accurate in hours, the actual duration may take longer due to additional related work (e.g. meetings, documentation) and non-related work (e.g. other projects). By observing the the velocity, you can predict a time frame, whereas, with time based estimates, you'll end up looking for the missing hours each sprint. – Danny Varod Dec 30 '14 at 19:07
@DannyVarod with those caveats it's worse than meaningless. And does nothing to solve actual resource leaks that prevent your project from shipping on time. – Chris Marisic Dec 30 '14 at 23:06
@ChrisMarisic on the contrary, you can measure the velocity changes and in the retrospectives see what can be done to increase the velocity. Also, estimates are never accurate, so using them to determine when development will end will never result in a correct end date prediction. If you estimate in points and reach a velocity with small variations, you can predict better. – Danny Varod Jan 1 '15 at 9:14
@DannyVarod that is entirely false about determining when development will end. You do not estimate a project. You estimate the discrete activities, insert them into a dependent network node diagram graph, calculate the floats, determine the critical path and then monitor the project updating the progress as you go. As long as your project is not rapidly eating float and your developers don't delay the critical path you know exactly when the project will end. – Chris Marisic Jan 2 '15 at 19:18

The essence of estimating in points is that it is based on relative sizing, whereas hour is an absolute measure. My 10 hours task could be your 5 hours task but we both would agree that creating a normal user registration page is smaller task as compared to creating a shopping cart module, so this approach reduces variability in estimates.

Give points based on how big/complex the task/story is and how much of it there is, for example there is a task which is quite simple but it has to be done multiple times then that task/story would be given higher points.

After completing a couple of projects, you would have a history of how many points your team covers in a specific time interval. This will be the team's velocity. The key point here is that you dont change the team size. Team member can be replaced but not preferred.

-
+1 for the parallel between `My 10 hours task could be your 5 hours task`. – Tiago Cardoso Feb 28 '12 at 15:08
A project plan should not care about your 5 hours or 10 hours. It should care about man-weeks. Your man-week should not vastly differ to a peer. The only sizable differences at a man-week level should be junior developer vs senior developer. – Chris Marisic Apr 2 '14 at 18:39
@ChrisMarisic When someone commits to frequent and continuous delivery of working software (recommended every 1-3 weeks) then week-level estimates would not be accurate. Have to come down to man-days or even hours. Apart from that, `My 10 hours task could be your 5 hours task` was used just as an example (a metaphor). – Aziz Shaikh Apr 3 '14 at 5:15
I'm not going to diverge into whether agile is a reasonable choice or not, but i will address the rest. What is the friction cost of dealing with assignments that measure in hours? You want to be spend time planning involving multiple staff members activities that are executed in fewer hours than it takes to plan them? Even if you're interested in doing continuous delivery, why wouldn't you want your team members to have activities that will actually span that? For activities that are so insignificant they take less than a day, why bother at all with planning? Just do it and assume 1 day. – Chris Marisic Apr 9 '14 at 14:01
If you have serious issues in sourcing a man-week of closely related work that can be handled by 1 developer, i would really question what value are you building if everything is completed in hours? Not to mention the user experience impact of this. Every week lets add 10 exceedingly small features with the knobs, bells, and whistles for all of them. developer.apple.com/library/mac/documentation/userexperience/… "Focus on Solutions, Not Features" "80% of users use only a handful of an app’s features" are you serving the 80%? – Chris Marisic Apr 9 '14 at 14:06

As always there is no simple answer to this question. I would say that you should choose what works best for you. However as you say working with hours doesn't work for you.

In my team it was the psychological aspect about working with points. When people are estimating in points they feel more comfortable, because there is no simple measure, that 1 point = 1 hour, so they won't be punished if it will take them more time to finish the task than they declared.

Another thing is that when working with points (1,2,3,5,8,13,20) or sizes (S, M, L, XL) you just define the complexity of the task. Velocity shows how many points you can put into the iteration, but velocity changes.

And than working with points is less frustrating - if you estimated badly your velocity will go down.

-
"so they won't be punished if it will take them more time to finish the task than they declared." what purpose is estimating if there's zero accountability to the person making the estimates? – Chris Marisic Apr 2 '14 at 18:40

It's all about abstracting away from a false reality.

Points are better than hours because they force everyone involved, especially non technical stakeholders, to internalize that building your own software is not like shopping for features in a store.

For better or for worse, business stakeholders almost always want to know "how much will each of my features" cost. Of course they usually start with such high level descriptions of features that any price estimate, in hours or dollars, is going to be laughable.

Agile in general and the points system in particular, force stakeholders kicking and screaming into the process of going from a high level business request to an iteratively refined implementation.

-
+1 for abstraction. It's missing in all the other answers – MorganTiley Mar 15 '13 at 18:39
So is 1 point \$1? Is 100 points \$10,000? That's meaningless. You can reasonably ballpark 1 man-week at \$2000 for most developers and for top caliber at \$4000 per man-week. – Chris Marisic Apr 2 '14 at 18:42

There are two reasons I like points over hours.

Hours have an implied precision and tend to be looked at as 100% accurate, all humans understand what an hour is so if you say 10 hours it must be ten hours. To compensate for this the person estimating will build in some "extra time" to compensate for the unknowns. It is just human nature they don’t want to be held accountable for an estimate when they didn’t have all the data needed.

The problem with this is the larger the task/story the greater the complexity and the more time it would take to develop a truly accurate estimate. At some point it is just not worth the effort. Especially when you are looking at work that will not be done for several months.

Points on the other hand have an “acceptable” implied imprecision since they are relative only to each other.

By using the Fibonacci series: 1, 2, 3, 5, 8, 13 etc. the team is able to compensate for both the complexity of a project and the expected effort. As the numbers get larger the fuzziness of the estimate is built in. Time is not wasted trying to determine if it is a 9 or 10 or 11, if it is larger than what the team calls an 8 and smaller than what the team calls a 20 then it is a 13. As the story gets closer to being accepted into an iteration it is further broken down and refined and the accuracy of the estimate improves.

By using this method the near term work can be estimated with a high degree of confidence, the further out you go on the schedule the confidence drops, but the team still has a good idea of the effort involved without spending an inordinate amount of time braking down a story that may never be done due to changing priorities.

jeff

-
"To compensate for this the person estimating will build in some "extra time"" very valid statement. Don't estimate in hours. Estimate in man-weeks. Very few people are willing to pad their estimates by entire magnitudes. Using your hours example, if they assume 8, they may answer 10. If they estimate 8, they're not going to say 16 unless they're intent on sandbagging you. – Chris Marisic Apr 2 '14 at 18:46

This is all rather misleading. The fact is, in our head, we tend to convert the points back into hours once we know our velocity. Purists can talk about points all day long, but it's just people trying to be hoity toity. Really the key here is to encourage people estimating to think in relative terms. i.e., this project is about as complex as that project and that project took X hours so this project should take x hours.

You might think you're pulling off some cool psych trick, but if your people are worth anything, they're doing the mental math in their head already.

-
well no, the problem is your thinking hours when you choose your points. I really couldn't tell you if a 5 pointer takes 2 hours or 5 hours or 2 days as it's relative to our 2 point callibration story, which could take 3 hours/ 1.5 days or a week. all I know is I think it'll take about 2.5 times as long. – The Wandering Dev Manager Feb 28 '12 at 18:54
I think your question loses value when you resort to insults (saying people are "hoity toity". While I agree that good developers do the point->hour conversion in their head, points are still valuable. On my team, I know a 4 point story is roughly one week of work for one person. But I also know it's not exactly one week. It might be four days, it might be six. What I do know is that it takes more than a two point story, and it's definitely not an eight. Using points means I don't have to commit to a specific number of hours or days. – Bryan Oakley Mar 4 '12 at 13:33
I've seen points getting converted 1 to 1 to days and it's just simply wrong. The idea is to abstract estimates away from absolute into a relative reference for the team. And the accuracy of these estimates will increase as time passes (and you review them). This is also why it's not strictly Fibonacci - use shirt sizes or some other arbitrary gauge if your people have trouble with Fibonacci – MorganTiley Mar 15 '13 at 18:45
@BryanOakley "it's not exactly one week. It might be four days, it might be six." and who cares? You can definitively call this 1 man-week! Plus or minus a day in man-weeks is all within any well designed project tolerances and slack time. (Any person that doesn't know what slack time is, isn't really qualified to be in this discussion) – Chris Marisic Apr 2 '14 at 18:45

Although probably not an intended feature, one of the benefits of using points from a manager's perspective is that tasks are measured by complexity rather than by time, which allows you to easily see who on the team works faster than everyone else. For example, you know that it takes person A 2 hours to do something, but takes 10 hours for person B (for a particular task; perhaps it is opposite for another task). If person A estimated 2 hours and then was out sick, person B would be 8 hours behind the estimate before even starting. But if you give it points, and then average for the team, you are more likely to hit your mark overall.

-

Hour estimates usually can be converted into points, but points estimates cannot, usually, be converted back into hours.

Be careful, once you switch to points estimates, there won't be an easy way back to using hours.

When would you switch to points, and other relative systems? When hours stop working for you. If you find that hours estimates aren't giving you a good handle on the time it will take to complete a project, you can still get an idea of relative complexity with points and other systems. This lets you ignore the time dimension, and get some complexity information.

In my experience, however, you'll have to get back to time estimates at some point, no matter what you're doing. So, if you're switching to points, figure out a way to also estimate time.

-

For my team, they frequently got hung up when estimating hours in getting minute details absolutely correct, but take wild guesses at other tasks. The result was very high variability in the delivery of stories. When we shifted to points, the team started doing estimates of whole stories based on overall complexity and their velocity became much more predictable.

-
So don't worry about hours. An hour is meaningless. Measure in man-weeks. If an activity can't be measured in man-weeks why are we even bothering about planning? Just do it, it will be done sooner than it takes to plan how long it takes. – Chris Marisic Apr 2 '14 at 18:47

Story points work best when the following conditions exist:

1. Organization has a high risk tolerance which allows for vast variances in planned to actual during the beginning of a new, hard to estimate project.
2. Teams work in a closed system, where all teams follow agile and teams are stable. No resources are shared and teams aren't required to interact with teams using other methods (e.g. Waterfall)
3. Teams have an engaged product owner or end user as part of the team
4. A dedicated test resource, automation or both allows for relatively stable testing estimates
5. The team coordinates the prioritization of technical debt with each sprint, along with the customer's priorities.
6. Planning only includes stores carried over to complete or stories defined as "good enough" to estimate (e.g. Good user story, business rules that are universal or specific to the actor, conditions of acceptance/ test criteria can be established within 24 days of tasking.
7. After planning with the product owner, teams are allowed "alone time" and technical guidance to discuss and prioritize the tasks.
8. During the sprint, the team assesses progress daily, collaborating and removing roadblocks. Teams stick to tasks they've committed to.
9. They're not required to complete standard or traditional documentation, such as a BRD or SRS, before work can begin.
10. Project commitments or other items the team can't control, aren't driving the sprint prioritization but are factored in an influence in planning.
11. Teams demo and correct within the sprint, as inputs to velocity
12. Teams take credit for work completed with a sprint, though the story may not be complete, but code is production ready - at least in part.
13. Teams take the time to analyze variances in velocity, what they need to improve in retrospectives, define a plan and measure their success.
14. Quality, bug free code is deployed on time, that didn't break anything else, and meets acceptance and testing criteria and hasn't left a backlog littered with massive amounts of technical debt.

If a team can't check each of those boxes "yep, we do that", your management its going to push back and a balance to manage the business will be the next step. As an earlier answer mentioned, teams should begin to plan for points and hours to address this scenario. Management knows each story point equates to some value in person hours. Identify it as a team or be prepared when it's defined for you by the business manner.

-

Some time ago I wrote a relevant blog post: "Hours of effort remaining"

The essence is that we are unable to estimate actual time and instead think that we're estimating in 'ideal hours' but we can't abstract from the perception of time. It can also create a false impression that the number of hours remaining are 'clock hours' as opposed to 'idealised hours'.

-

I agree with the comment Blaze a little bit but I will try and make a happier case for it:

Truth be told, it usually is length of time for a task that you are interested in, so that you can estimate how long future projects, of similar complexity, will take.

This is how you end up using the velocity as mentioned. After a few development iterations which take x amount of time and have y number of points allocataed, you can get your velocity and then use that to plan for the future.

It's a great thing to be able to do that and a really useful tool for developers, management and product owners.

-

Story points work best in Scrum because of the mindset of the method.

In my experience Scrum is one of the only methods that allows this because in Scrum management must be hands off. Scrum gives a certain amount of freedom to the development team to complete all the backlogs without interference from management (and PM's) until the end of the sprint. So asking how long a single Story will take to be developed will be irrelevant.

For example, Story A takes estimated to about 5 Story Points, and the total amount of Story Points in the next 2 week Sprint is about 20. If you as a PM need to know how long Story A will take to finish, well... 2 weeks is your answer. In parallel with the other Stories in the sprint.

In the end, you can always try to calculate the ratio of man-days per Story Point. In the case above, 20 Story Points will take 2 weeks (10 days). Meaning it might take 5 Story Points task will take 2.5 days. But in Scrum, you don't package the release after 2.5 days. You must wait until the Sprint has finished, which is 2 weeks. Which makes the ratio of man-days per Story Point rather useless.

Don't forget, as a PM, you need to monitor the velocity of the team and make sure that the team has a steady amount of total Story Points to work on each sprint.

-

The point system is based around the behaviour of "chunking" and while it gets people to communicate the overall duration vs complexity matrix at the end of the day it will still distil down to time based calculation (whether at the time of the team doing the sequence forecast see's it or not).

There is an element of danger here in that i see allot of teams assume they've "money balled" development, they've finally cracked the secret to forecasting by math! - its a false positive because if someone allocates a Story with "small" (t-shirt size approach) and that person then decompresses 20 tasks to make that story complete, then each of these tasks are still allocating time variables to the equation.

This isn't a bad thing, as all the chunking sequences are doing is setting parameters around how much the team "Allows" in terms of not just investment in the task but also the types of developer skillsets required to make the task happen.

As a team manager, you still need to know time + task, and it's not to penalise a developer for failing to hold his/her time budget into place. It's more to act as a way to monitor their growth or ability to help them nurture better communication behavior - "Sam doesn't like to ask for help" so it enables the leader to help rehabilitate the behaviour towards "be ok with failure, failure teaches you life's lessons". It also lets you put a junior developer on a senior task, because you want to see how well they will fair...yes they will overshoot the point system estimates but that's part of on the job growth training and so on.

Like I said, you can "game" the forecast modelling with abstraction techniques as the point system, but when it comes to allocation and even velocity, time is still lurking away. It's why you most teams do the x number of weeks is a sprint, when if it were truly an abstract methodology it would be "this is a 45 sprint and next one is an 24 sprint" or something like that... the sprint would be variable in length & time. Instead you find yourself in this cognitive dissonance around shoe-horning abstraction of points into relative time? but using arbitrary baselines to quantify the data some how?

-

Another point to add is that the team often estimates the work ahead of doing it. Time based estimates are particular to the people completing the work. Relative sizing (Story Points using Planning Poker) is the size for the team. It is not people specific.

Basically time and story points are not equivalent.

-

Points add an abstraction away from time for psychological reasons, implicitly to prevent programmer burnout. Somebody still has to turn the abstraction into a time/financial cost. It just passes up the chain until somebody is willing to take responsibility for it.

My own view is that programmer burnout is not caused by attempting to estimate in time, it's caused by inappropriate management reactions when things take longer than expected.

If you're making up abstractions to avoid giving a commercially useful estimate because you fear punishment that much, the problem is with your management culture.

It's better to have a supportive environment where sincere and hard working people are understood to make some mistakes, but where's there's transparent feedback, rather than adding layers of abstraction so they don't have to confront realities like 'I thought this would take a day and it's taken over a week'. To my mind, that's treating engineers like children.

-
Hello and welcome to PMSE. Can you please elaborate how your answer contributes to the original question of points vs hours? – Alex Leonov Dec 30 '14 at 19:20

Story points should not be used for project planning. There is no purpose. Estimations should be built in man-weeks or man-months. Story points do not readily present any information that is able to be acted upon. A story is weighted at 10. What is 10? Is that 10 for 1 person, is that 10 for 100 developers working on the project?

The usage of man-weeks is straight forward.

In the end estimation whether it's points or time... is an estimation. It is based on the experience of the person creating the estimation. By using time directly you have a much better ability to measure the success of your estimates. Comparing story points to story points is at best fuzzy, and at worst meaningless.

Lastly, how do you build a system with story points? How many team members do we need? When will it be done? Time and money is business. Project planning is to give the business information on how to best apply their time and money, story points are neither.

-
Estimates are not that useful for project planning in general. Whether in points or time. Instead, where possible, lead time per service type combined with probabilistic forecasting will generate a more accurate picture of how long things are likely to take. Also 'measuring success of estimates' is of little value. Measuring value generated and ROI is far more useful. Further to this, if you want to estimate anything, why not estimate how valuable a work item will be on delivery rather than how long it takes to build? – Ian Dominey Jun 6 '14 at 5:41
@IanDominey "why not estimate how valuable a work item will be on delivery rather than how long it takes to build?" that's actually a reasonable statement. Agile was built specifically for the purpose of making modifications to an existing project. It was never intended for new development (aka to replace project design). If you're doing iterative development on an existing product that does not reach a scope of requiring a new system to acheive it (even if that system exists inside the current) it would be very reasonable to measure work-item-value-points and prioritize accordingly. – Chris Marisic Jan 2 '15 at 19:26
In practice, agile is used to replace the need to do project design. It leads to the absence of design. This is not just wrong, it is the opposite of correct. Systems are not "emergent", architecture is not "emergent". – Chris Marisic Jan 2 '15 at 19:26
I could not disagree more. Agile is used to embrace the reality that at the start of a project, you are about to embark on a journey of knowledge discovery that, by definition, contains a multitude of unknowns. Systems are indeed emergent, I challenge you to find many examples of effective systems that were designed up front rather than having been adapted to meet an emergent understanding of need. – Ian Dominey Apr 29 '15 at 14:52
@IanDominey blog.ts.fujitsu.com/face2fujitsu/index.php/… don't worry, it's only integrated with over 80,000 stores. It's not like custom workflow and remote integration is a difficult problem /s. Systems are not emergent, functionality should be emergent. A well designed system is capable of surfacing all relevant business use cases. – Chris Marisic Apr 29 '15 at 15:10