7 December 2012
Now why haven’t I talked about time in the previous chapter? Because using time for our estimates is very dangerous. When you ask someone how long something is going to take and they say 1 hour, your initial reaction is to expect it to be done the next hour. It’s not because we are egotistical or evil. Again, it’s just how the human brain works. So if you say you can have a work item finished in 2 days and then start explaining that they will get it in 2 weeks, it will immediately cause tension in people’s minds. There are two options to avoid this: either using an abstract unit of measurement or using a range instead of one number. You might have heard about the concept of story points before, it’s something a lot of agile teams use to express the effort that is related to a story / piece of work to be finished. This effort does not only include the actual size of the work, it also takes into account the complexity of the work to be done as well as the uncertainty people have about the actual work.
I’ll try to explain this in more detail using music. Imagine you have to estimate the effort it will take to learn how to play a new piano concerto. Some of them are extremely complex to play, because they have lots of different phrases and makes them hard to learn. Even though the phrases themselves might not be that hard to play, the shear amount of new phrases to study will require a serious effort. Other pieces are harder from a technical point of view. They don’t have the same amount of phrases to study but some of them are just complex to play and therefore study. And then imagine having to give an estimate on the effort about a concerto that you have never heard or even heard of. And to make matters worse, you don’t get the sheet music. Even if it is a very simple piece to play, you will still estimate this as a big effort because you have no idea what to expect. One last thing about using story points. It’s very important to use a good scale for this unit of measurement. Scientific studies have come up with what we call the cone of uncertainty, visualizing the amount of uncertainty in relationship to the point in time of a running project.
Nothing enormously surprising about this: the earlier in the project you are, the more uncertainty you have about estimates and the closer you are to delivery, the more certain you are. So in order to use this concept as well as avoid debating for hours on the “perfect estimate” (think about the effort – accuracy graph from the previous chapter), a lot of people have experimented with different sequences and came up with a version of the Fibonacci row to be the best suited. The gap between two consecutive numbers grows exponentially with growing numbers. This takes the cone of uncertainty into account. The bigger the chunk of work to be estimated, the bigger the uncertainty of our estimate. The typical example would be 0 – 1 – 2 – 3 – 5 – 8 – 13 – 20 – 40 – 100 – … So it would not be very useful to start discussing whether some work item is a 20 or a 21. The difference is so small and our uncertainty about it so big, that this effort of discussing it further will not increase the accuracy by much. So it’s not worth it. Is this new piece of work closer to the things we estimated a 20 or to a 40? That’s enough effort for a good enough estimate.
This approach of relative estimates using story points is something we will typically use when we apply the scrum framework.
