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?

  • 12
    "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. Commented Apr 2, 2014 at 18:37

19 Answers 19


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"

  • 16
    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) Commented Jul 20, 2011 at 8:27
  • 5
    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? Commented Nov 28, 2012 at 21:59
  • 4
    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. Commented Dec 3, 2012 at 18:18
  • 3
    @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". Commented Jan 24, 2013 at 20:32
  • 12
    @Eric great answer. Unfortunately, video is not available in the provided link. Commented Jul 29, 2016 at 6:53

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.

  • 6
    "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. Commented Apr 2, 2014 at 13:31
  • 1
    @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. Commented Dec 30, 2014 at 19:07
  • 1
    @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. Commented Jan 1, 2015 at 9:14
  • 2
    @ChrisMarisic ... Maybe, if we start treating business like elementary school, we will begin to enjoy ourselves a little more.
    – Nicholas
    Commented Aug 10, 2015 at 21:09
  • 2
    @ChrisMarisic "no one cares about effort": effort as a metric is time spent working. Oh yes, businesses care a great deal about that.
    – Esteban
    Commented Jan 14, 2016 at 16:01

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 more points.

To start with, you would need to choose a couple of tasks/stories that are of medium/average complexity/size. Assign them some points from your selected range of points (usually Fibonacci series). These tasks/stories become your reference tasks/stories. Now assign points to the rest of the tasks based on how complex/big each task is relative to your reference tasks. Bigger tasks get higher points than the points give to reference tasks. At the end of estimation exercise (usually performed using Planning Poker) you sum up all the points to get the total estimated points for that project.

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 don't change the team size. Team members can be replaced but not preferred.

  • 12
    +1 for the parallel between My 10 hours task could be your 5 hours task.
    – Tiago Cardoso
    Commented Feb 28, 2012 at 15:08
  • 1
    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. Commented Apr 2, 2014 at 18:39
  • 1
    @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). Commented Apr 3, 2014 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. Commented Apr 9, 2014 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%? Commented Apr 9, 2014 at 14:06

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.

  • 2
    +1 for abstraction. It's missing in all the other answers
    – Morgan T.
    Commented Mar 15, 2013 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. Commented Apr 2, 2014 at 18:42
  • @ChrisMarisic Points change in value over time; one iteration a point may have worked out to three person-days and ten iterations later a point may be only two person-days. That points can more easily adjust in value in this way is one of the reasons to use them over estimates in hours or days.
    – cjs
    Commented Feb 19, 2020 at 7:50

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.

  • 2
    "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? Commented Apr 2, 2014 at 18:40
  • 1
    The rationale is that software is inherently difficult to estimate, unlike for instance civil engineering. But over time, your estimation errors will fall into a normal distribution. To miss the exact estimation should be accepted when developing software. That requires trust, not punishment. Ironically, trusting and caring about people is a requirement to build a high performance team and earn more money.
    – Jano
    Commented Mar 4, 2018 at 0:37

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.


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 breaking down a story that may never be done due to changing priorities.


  • "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. Commented Apr 2, 2014 at 18:46

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. Commented Apr 2, 2014 at 18:47

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.


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; e.g., this project is about as complex as that project and that project took x hours so this project should take y 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.

  • 4
    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. Commented Feb 28, 2012 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. Commented Mar 4, 2012 at 13:33
  • 2
    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
    – Morgan T.
    Commented Mar 15, 2013 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) Commented Apr 2, 2014 at 18:45
  • So when you decide how long it will takes, do you already decide who'll take the task ? Some things I can do in three hours might take a week to a junior, how do you address that fact ? And if the task can be done in a few hours, do you use 0.20 man-week ?
    – Jemox
    Commented Mar 24, 2023 at 15:25

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.

  • 1
    Hello and welcome to PMSE. Can you please elaborate how your answer contributes to the original question of points vs hours? Commented Dec 30, 2014 at 19:20

The short-answer would be that "hours are only a guess, at best." But if you look at story-points – call them what you will – you are considering the activity map (and the naturally-occurring dependencies within that map) which will eventually cause those billable-hours to be spent.

"Computer software," in particular, is a rat's nest of interlocking dependencies. When you examine the software from a functional point of view in this way, you are really looking to uncover the complexity and interdependency that so often puts a project on a "death march."


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.

  • 1
    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? Commented Jun 6, 2014 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. Commented Jan 2, 2015 at 19:26
  • 1
    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. Commented Apr 29, 2015 at 14:52
  • 1
    I refer you to the entirety of nature which is an emergent and non-designed system. Oh, and the Internet itself. And society. Commented May 15, 2015 at 10:16
  • 1
    Story points don't build bridges, engineers do. And unlike bridges, which are well understood and defined, much software of high value is a knowledge learning process in action. Bridges are a poor analogy for much of software. Software development is more akin to running multitudes of experiments than building bridges. That's a large part of why a lean and agile approach exists. But back to the original point - story points are a useless abstraction that allows us to over-confidently believe that we can accurately guess how long something we don't understand will take. Commented May 19, 2015 at 20:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.