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