Do Estimates Do What We Want Them To Do?

I’ve noticed that there seems to be a lot of people who feel they get a lot of value out of doing estimates*.  There also seems to be a growing number of people who suggest that estimates* are wasteful and even harmful to a project.  Whichever works for you, either way, use it. I have only one thing to suggest: Do your best to make sure you are not blinding yourself from finding new and better ways.

[Disclaimer: I am only talking about Estimates* as used in software development as part of planning or otherwise. See notes below]

I take the “not blinding myself” very seriously. Here is my Agile Maxim about that:

Agile Maxim #3 – Question Everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.

[ You can see more thrilling and uplifting Agile Maxims here: Agile Maxims ]

You are perhaps thinking “But Woody – you seem to have a very deeply held belief that Estimates* are Useless and Wasteful – you should practice what you preach and Question That!”

Some will say “Woody: You should Practice what you Preach!!!”

You are absolutely right – I should practice what I preach. (By the way – I don’t believe that all estimates* and estimating* is useless and wasteful, just a great deal of how they are typically used in software development).  And of course, I have gotten to where I am in my thinking about estimates* by questioning the value and usefulness of estimates* over a long time – in both the realm of software development as well as other fields I have experience with.  Yet still, EVERY DAY, I re-scrutinize my thinking on the value of estimates* – and whether or not we should use them.  Sometimes more time, sometime less time – but it is rare that I don’t think about the usefulness of estimates* (or of not having estimates*) at some point in the day.  If estimates* bring value, and I am losing out on that value because I am too bone-headed to see it, I want to be set straight. And on the team I work with we constantly experiment and try  new things, old things, different things, same things – whatever we feel we need to do to learn and make things better.

So… here are the sort of things I ask myself or consider every day about estimates*:

  • If I found that estimates* are indeed wasteful, what would I do?
  • If I found that estimates* were misleading and giving us bad information, what would I do?
  • What if estimates* never existed – if they were never invented… is there some other way we could work?
  • What if there is a better way to get the right work done using some other process, would I still estimate*?

And it goes the other way:

  • What if we were not able to make decisions unless we had estimates*, what would I change about our work?
  • What if we needed estimates*, but the estimates* we were doing were not very good, how would I fix that?
  • What if estimates* provide a way to see into the future and make GREAT decisions, what would I do?
  • and so on…

And so on

This whole questioning process takes little time on a daily basis.  Occasionally, I scrutinize this sort of thing to a much deeper level – sometimes in a focused retrospective, or just thinking for a while, or in talking with other Agile-maniacs, or even by doing (or attending) a session at some user group or Agile Open event. I WANT TO KNOW THE TRUTH!  I want to steer and adjust my thinking.  I have no pride – if I learn a better way, I will evaluate how to incorporate it into what we’re doing – and experiment, reflect, tune, adjust, throw out, bring back, etc.  I am always open to THROW OUT THE OLD if it is no longer useful.

Bottom Line

I don’t care if you use estimates* or not.  If it brings value to you, do them. If you want my opinion: I suggest you find a way to make sure they help and don’t simply use them because “that is how we do things”.

To quote the poet:

Whatever gets you through the night, it’s alright, it’s alright.


* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.

Leave a comment