Danger?! I laugh at danger, you might say. However, estimates can set some unrealistic expectations and undesirable behavior – both at the management level and at the team level. If you are not careful, you may end up like this guy.
First, think about how estimates make you feel. Do they make you feel uncomfortable, irritated, and maybe even a little bit queasy? These are all normal feelings during the estimation process. You are trying to estimate something with varying degrees of uncertainty and you might be held to that estimate later.
An estimate is a guess, based on the experience of the team and agreement by its members. It is not accurate, it is an estimate, not an “exactimate”. Yet, for some reason, an estimate sounds so official, so final even, that an unnatural amount of weight is placed behind it – even after it is no longer valid.
So why are estimates dangerous?
We can hold on to them for too long. When estimating, there are three levels of certainty. There are those things that you know are known (known knowns), those things that you know you don’t know about (known unknowns), and, lastly, those things you don’t know that you don’t know (unknown unknowns). The unknown unknowns, and to a lesser extent, the known unknowns, can upend estimates and change the timeline of a project. Yet we can still hold onto the estimate throughout the life of the project for some inexplicable reason.
The first estimate given becomes the ‘gold standard’. No matter who estimates the work first, this estimate will be seen as the ‘right’ one. It doesn’t seem to matter which team ends up doing the work (and the re-estimate), the first estimate is what is seen as ‘correct’. The higher the person is in the corporate hierarchy, the longer they will generally hold on to that first estimate.
An estimate can predispose us to a solution. The team will often estimate the work based on a chosen direction. If they find a better way during their journey of inspection and discovery that also requires some rework, but prove the estimate to be incorrect, they may very well stick to the original direction in order to deliver on-time. This can limit creativity and innovation by the team.
More time spent estimating is counter-productive (a/k/a the law of diminishing returns). Some teams, perhaps having been burned by some of the prior dangerous behaviors, can start to spend too much time estimating in order to ‘get it right’. Studies prove that while you can gain additional accuracy in adding more time to the estimation process, the benefit does not justify the cost and can begin to eat into valuable time better spent actually addressing the work to be done.
Estimates equate to feasibility. Just because an estimate is produced, does not mean the work is feasible. However, if you ask for an estimate and not a feasibility study, an estimate is exactly what you will get. I can give you an estimate to build a stairway to the moon, but is it feasible?
Overestimating. If the team delivers ahead of schedule, they could be questioned by management about ‘padding’ their estimate. This may not be the case at all since the team could have discovered efficiencies in how they work or discovered a better way to implement the solution. The team should be applauded for their results, not questioned.
Underestimating. If the team did not account for something in their estimate that endangers the delivery date, they can often be held to this date. When this occurs, the team could potentially cut corners or work insane hours (increasing the chances for mistakes to be made) in order to meet the date.
What dangerous behaviors have you seen associated with estimating?
So what can be done?
Unfortunately, not much. As long as estimates are expected in the software industry, they will continue to be delivered….and we will still see the behaviors outlined above. In the future, we may see no estimates at all. In fact, a movement is already underfoot to do just that. For the short-term, perhaps we should start calling them “guesses” and not estimates, because then the perception would change.
In the meantime, as you continue estimating, face the task like this guy.