The Art Of The Finger In The Air

Estimating is a part of a developers world, hardly any conversation with a non-developer will proceed for long without one of the following being asked,

"How hard do you reckon that is?"

"How long will that take?"

These questions are usually accompanied by a sigh from the developer before he or she tries to give his or hers best non-committal answer.

Unfortunately estimating has become a game we play rather than an effective use of our time.

Estimates Aren't Weapons

One of major reasons for this is because estimates are seen as synonymous with commitments, once a team has given an estimate its often filed away as ammunition to shot them down with in the future.

Estimates are given in the moment, their quality should be measured in comparison with the amount and quality of the information available at the time. When this information changes either in quality or size we should expect that the estimate will change.

We also conversely shouldn't expect the estimate to change when the information doesn't change, asking the same question until you get the answer you want is a good definition of a waste of time.

As estimates get better we mean that they are getting closer to reality not that they are getting bigger or smaller, the only time you will be able to truly accurately estimate a project is the day after you finish it.

Estimates Should Be Relative

Estimates are best used when they are stacked up against other estimates, providing those estimates are based on the same quality and amount of information.

If feature A is estimated at four weeks and feature B is estimated at eight weeks, the important thing here isn't the actual numbers its the fact that based on the information we have feature A looks like its half as complicated as feature B.

This could be because feature A is actually easier to implement than feature B or because feature A is better defined than feature B.

Many factors may go into our next step we may chose to go with feature A or we may chose to simplify feature B or to fill in the gaps in its definition to try and increase the quality of the estimate, again by quality we mean closer to reality not smaller.

Either way we gain a lot more insight then if we only knew that feature B was estimated at eight weeks.

Estimates Don't Identify Risk

Estimates are often seen as managing risk when in fact its the information gained in trying to estimate that is truly identifying the risk.

What do we understand about the risk of feature B by knowing it is being estimated at eight weeks? What about if we knew the estimate was higher because developers were worried about the amount of server work required?

Is the best course of action to hope the developers are right and feature B will take eight weeks or to see what can be done to reduce the amount of server work involved.

It may be that nothing can be done but by not just asking for the estimate but by also asking for an explanation as to the factors that went into making it we understood a lot more about the problem and where the risk was.

Agile should be all about communication, quite often the discussion is more important than the answer it brings.  

Estimate Value As Well As Implementation

To take the idea of estimates being relative even further we should also estimate the value that we expect a certain piece of work to bring.

In planning poker what if Product Owners, and why not users, were asked to estimate the value they thought a feature bring? What if we could identify features that score 3 for implementation but 13 for value?

Agile and MVP should be all about identifying situations like this were a lot of value can be gained from small amounts of effort and even more importantly identifying when a large amount of effort would be wasted on delivering little value.

In reality it won't always be possible to identify situations like this, quite often value and effort will be proportional and broadly in line but the occasions where you can identify the mismatch will give you a big advantage, they will help you be the first to market delivering clear value.

Estimating Isn't Just About Numbers

The most frustrating thing about the estimating game we play is that we all know it doesn't really work.

Developers know when the estimates they are giving aren't based on reality, and Product Owners and Project Managers know the sense of security they are taking from the estimates is false.

We need to stop thinking of estimates as being numbers that we can plug into a plan we won't follow and instead see them as a process by which we define the outcome we want and iteratively zone in on when we think it may be delivered.

This does require us to acknowledge some things just can't be estimated accurately if their is not enough information about the intended outcome.

For example if I asked you,

"How long will it take you to bake a cake?"

You might reasonable ask, "What sort of cake?" and we can continue the conversation until we know exactly what kind of cake we are after.

The same applies with software, don't ask your developers to estimate the length of a piece of string, work with them to draw a sketch of the string that way you'll both know how long it is.