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?
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 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.
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.
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.
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.
My 10 hours task could be your 5 hours task.
Commented
Feb 28, 2012 at 15:08
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
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.
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.
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.
jeff
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.
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.
Story points work best when the following conditions exist:
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.
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.
