People need to estimate as part of planning. It can be time (tasks), money (budgeting) and so on. The point is to understand the value of something. We can then decide if it's worth the time or money or in what order should we do/get things. When working with tasks we focus on more valuable actions first and if there's time we complete the rest later. We also want to know when a project will be done.

So, software developers are often asked to estimate. We often miss and underestimate. Why? Here's my list of the possible reasons. There are many books written on the subject. I have hardly read any of them so I probably miss something.

• We've never done it before, so we have no idea how long it will take. We just guess.
• We lie, because we wish we would have been better developers and could develop it quicker, or because we want to tell somebody what they want to hear, not our opinion.
• We fail to fully grasp the scope. We estimate what we see, but there are a lot of hidden additional work.

In the first case it's just a matter of experience, but I don't think this is a big factor. In either case there's not much we can do about it. I'm stuck with whatever experience I have.

In the second case, we just need to learn to be honest and face the truth, even if it's not pleasant. It might be hard to acknowledge the problem and do something about it now, but later on it will be more expensive and more unpleasant. This is applicable to all aspects of life. People hide from reality, hoping that the problem will go away on its own. It might, but if it doesn't, it grows like a weed.

We can actually do something about the last case. When we make mistakes in estimation we are consistent about it and we can compensate for it. That's exactly what an estimation point system and velocity are designed to do in Agile Development.

While listening to Agile Estimation podcast I finally understood how point estimation works. Each point is just an abstract unit used to measure relative size of the task. It assumes that it's easier for people to estimate relative size of two objects or tasks when they compare them side-by-side than to estimate an object on its own using standard units (time, length, etc.) The size of 1 point is unique for each project and each team.

When estimating we don't know yet how long it will take us to complete each point, but we can say that 4 points task is twice as large and will probably take twice as long as 2 points task to complete.

Velocity is how many points are completed during each iteration (a week, 2 weeks or however long an iteration is). At first we don't know how big it is, but after a few iterations we can look back and guess how many points we will be able to complete in the future. This makes it possible to project when the project will be done, while compensating for estimation mistakes.

There's more I want to say about estimation and I will continue writing about it in my next post.