Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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?

share|improve this question
    
"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 at 18:37
add comment

17 Answers

up vote 56 down vote accepted

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"

share|improve this answer
7  
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
1  
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
1  
@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 at 19:09
add comment

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.

share|improve this answer
1  
"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 at 13:31
add comment

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.

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 excercise (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 dont change the team size. Team member can be replaced but not preferred.

share|improve this answer
6  
+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 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 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 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 at 14:06
add comment

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.

share|improve this answer
    
"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 at 18:40
add comment

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.

share|improve this answer
    
+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 at 18:42
add comment

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

share|improve this answer
    
"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 at 18:46
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
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. –  Mark Chapman 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 at 18:45
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 at 18:47
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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