It doesn’t matter what is your role in a software project or how do you call yourself in a company. Whoever you are — be it project manager, software analyst, engineer, or tester — sooner or later, you will be asked to make estimates. And because things are not certain most of the time in software development, estimates are very important. For some, making estimates is an art, for others it is a black magic. Once you learn more about the subject though, you will find out that it doesn’t have to be magic at all.
There are a lot of books on the subject, but I think that it is important for everyone to know some basics and it doesn’t matter whether you are the one making the estimate or the one who is asking for it. It is important to know what an estimate is and how a good estimate looks like.
“How long will it take you to do it?” When you hear a question like this, do you think that you are asked for an estimate or for a commitment? Indeed, there is no single answer. But next time you hear it, make sure that you understand what you are asked for. The mistake to consider an estimate to be a commitment or vice versa is very common. At one of the companies I worked before, every time they asked for “estimate”, they actually meant “commitment”.
Also estimates, unlike commitments, can be changed. Whenever you get more information or something changes, feel free to change your estimate. The goal of the estimate is to be accurate as much as possible based on available data. When you estimate schedule, you can usually see halfway through the project whether the estimate was good.
So what is an estimate? Oxford dictionary says: An approximate calculation or judgement of the value, number, quantity, or extent of something. The estimate can be basically a guess or more or less precise calculation. For software estimation, it is always better to stick to calculation. People are bad at guessing in general and have many biases. For one, it is proven that programmers tend to give rather optimistic time estimates.
Usually, the basic operations are count and compute. First, you count. It is possible to count many things, for example number of features, number of defects, lines of code and so and so on. After that, you compute, which usually means that you compare collected data from the previous step with some historical data and you derive estimate from it. The more historical data you have about the team, projects, tasks, features the more accurate the estimate is going to be.
You can estimate time, effort, size, schedule, budget or anything else. The important thing is to know what you should estimate, what is the final goal. As it happens, some of the things are often fixed. Say — the budget or the release date is already decided, then it makes sense to estimate number of features that can be part of the final release.
In a nutshell:
- Know the difference between estimate and commitment
- Think of estimation more as a calculation where you count certain features and compare them with historical data
- Feel free to change estimates based on available data