Estimates: any value in them?

Estimates are a highly discussed topics (not only) in the agile community. There are opinions we should abolish estimating altogether and then there are others who advice that we should estimates and that estimating has some benefits. So, can estimates be useful?

Estimates are… guesses, and they are wrong

“Prediction is difficult, especially when dealing with the future” — Danish Proverb

Before we start, it is imperative to understand that every estimate is a guess or a prediction and therefore is never accurate. Yet we tend to treat them as commitments, as something we can 100% rely on.

To better illustrate this, let’s have an example. I live some 20 kilometers away from my parents. Yet when I go there, it can take anywhere between 20 minutes and over an hour, depending on traffic. And this is simple — I use the same route every time, drive the same car, don’t stop anywhere during the drive. So the conditions are pretty stable.

Now imagine estimating a projects where you have shifting features, multiple people working on that stuff and even the uncertainty how to technically achieve something. It is many times more complex than driving from place A to place B. Does it make sense to demand precise estimates? No.

On software projects, other things may also change — for example our understanding grows over time (leading to more precise estimate and perhaps even in greater speed). People working on the project may also change — again, invalidating the estimates. To sum it up, when estimating, always remember that all estimates:

• are only guesses and therefore can be accurate, but are never precise,
• change over time and are never static,
• usually change during time,
• should never be confused with commitments.

Why do we estimate then?

“Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law” — Douglas Hofstadter

Despite estimates being guesses, we sometimes have to do them. Usually, especially in larger companies, we need some estimates to get budgets approved. We may even need estimates to prioritize features we are planning to implement in our products. We may also need estimates to know when something will be “done” so we can plan marketing campaigns, trainings, sales promotions and other activities.

All these reasons are valid. Problem is that usually, we try to make the estimates over-precise before we have the information to be able to do so. For example, I have seen a company where release dates have been set on a yearly basis, so in January everybody knew on which day in November the product will be released. Does that make any sense? It does not, because such a date has no meaning — it does not help you with planning marketing campaigns, training — because you don’t know what you will deliver after one year of work.

When you are faced with the request for estimating something big upfront, try to do the following:

• ask how much is the company (or your customer) willing to invest in the product (or the features in question) — in other words, what value does it have,
• ask what is the purpose of the estimate (what will we use the estimate for?),
• clarify and agree high-level features that should be included in the estimate (don’t go into too much detail — the uncertainty is so high that going into detail has absolutely no value),
• timebox the estimation itself (my rule: never spend more than half a day doing this kind of estimate),
• communicate the estimate properly — you might want to use confidence range, probability percentage or something similar to clearly state that the estimate is a guess,
• re-estimate periodically as you progress with your work, so that you provide more accurate estimates.

The idea behind this process is to have a common understanding and limits (if there are any) at the beginning and giving some information regarding estimates as early as possible and then refining that estimate as we proceed and learn. You don’t want to spend too much time estimating, as estimates don’t have any value by themselves — the work that you deliver does.

Before you start working, you may also want to ask what are the constraints of the work you are about to do:

• time: there is a promised delivery date, which must be kept — in that case, estimates make very little sense, as the date is already defined; however you still can play with what you will deliver (scope) and how much will it cost,
• scope: there is a feature set that needs to be delivered — in this case, you may be able to come up with an estimate range when this feature set will likely be finished,
• price: there is a fixed price to be paid for the scope to be delivered — this is the worst option possible, since it allows you with almost no maneuvering space, but you may still be able to play with the scope and at least confirm what may be delivered at the given price and with what probability.

Some of the traditional managers tend to fix all of these constraints — demanding you to deliver scope A by the date B and costing no much then C. This, due to estimates being wrong, is impossible to do. The only thing that this forces the delivery team to do is to make the only available thing variable — and that thing is quality, something you really don’t want to compromise.

Estimating in small chunks

Agile estimation techniques try to get around many of the problems by trying not to provide precise estimates, clearly stating that estimates can change and can be wrong and by focusing on priority (because priority equals value and value is what you want in the end).

When you are in an agile environment, you should always insist on having a prioritized backlog, so you work on the highest priority features first. These features should also be pretty small (so that a team is able to deliver a couple of them within a sprint), which may eliminate the need for estimation altogether.

You may want to use the estimates to calculate long-term velocity of your teams, giving your stakeholders greater visibility in how fast you are going. However, you might be able to achieve the same thing using just the number of items you are delivering every sprint — this is something that comes from the #NoEstimates community and to me it sounds like a good option, because it sort of pushes you to make your backlog items smaller and also removes the pointless discussion about whether a story is worth 1 or 2 points.

Are there any benefits of estimating work?

If you are trying to precisely estimate large chunks of work, then I’d say no. There is no benefits in estimating. Estimating in such a situation may actually be harmful, because it may be interpreted as a commitment.

If you are estimating small items, such as small backlog items in agile, I still believe there is one valuable benefit: the conversation the team has around that item and the alignment and shared understanding emerging from this conversation. The estimate (number, t-shirt size, whatever) is a by-product of this and I find this by-product of very little use. You may still want to play planning poker just to align the team and then not using the numbers once all team members are confident enough they understand the item.

So… estimates are guesses, not commitments

So, that is about it. You may find yourself in a situation where you just have to provide an estimate. But to sum it up, always try some of the following:

• never provide a single estimate — always go for a range, probability or some other technique to communicate you are guessing,
• ask why is the estimate needed and try to point out that time spent estimating is time spent not delivering any value,
• try to provide a gross estimate and agree on periodically refining it as you go,
• limit the time you spend estimating.