Estimates are always low so dates are not often met.  That is a common occurrence in today’s software environment.  There are many, many approaches to this age-old question.  Relative estimation, no estimation, ideal days, and some fancy-shmancy techniques that are mathematically sound (given a few unsound assumptions) that are significantly impressive to those so inclined.

Whatever technique teams choose, they are often still disappointed.  So what gives?  Is there a practice out there that can save us?  My answer is both yes AND no.

The no part is easy. No, there is no one practice out there that can give us accurate estimates. Estimation is fortune-telling.  And all fortune-tellers (at least in software) are wrong.  Estimation is a lie.  Pure and simple.  But it is a very useful lie, because it really helps to have some indication about what and when we’ll get things done.

The yes part is a little bit more involved.  And it comes at the problem side-ways.  Instead of considering the estimation practice itself, let’s take a closer look at how teams typically fail with all estimation techniques – and then address the commonality instead.

Choose any single technique out there.  Whether it is relative estimation or anything else, there is a really good chance it is not just marketing fluff or bullshit.  In fact, there is a really good chance that some really smart effective people used it successfully and have probably helped others use it successfully also.

So what gives?  Why were these techniques successful in some places and unsuccessful in others?  Well, there could have been many reasons, here are some of the most common ones:

• The original context was different, and it needs tweeking for the current context,
• The technique was modified because it didn’t “fit” into our context, instead of trying to take the (usually negative feedback) and change the way we work,
• We weren’t very disciplined in using it, because it was too hard, (check out We tried baseball but it didn’t work)
• There were significant failures, and instead of taking that as a sign of the method giving us feedback, we took it as a sign of the method failing,
• etc…

So let’s get back to yes, these methods actually work.  What I’ve found, again and again, when it comes to estimation, is that we are not able to effectively manage our agreements around how we will estimate and manage those estimates together.  We are not able to handle failures when they happen.  We are not able to confront issues when they arise.  We are not able to be disciplined in what we do.

These methods, like any methods, can be seen as agreements made amongst team members about how they will work together.  So if estimates are always low, then perhaps we need to look at our agreements; especially those we have broken.  And, perhaps, there is a reason that we are constantly giving low estimates.  Here are some of the ways some of the invisible impediments get in the way:

• Safety:  Perhaps the #1 culprit when it comes to estimates.  If I don’t feel safe giving what I *really* believe something will take then you won’t get a good estimate from me.  If I don’t feel safe calling out an unreasonable estimate early – then there will be a problem.  And, perhaps the most common instance of all, if I don’t feel safe to say “I was wrong, I need more time” early on – then I’ll just soldier-on.
• Respect:  Many times we don’t respect each other.  Take the common “Us vs. Them” mentality that is so prevalent in today’s business culture.  If the “Us” is managers, and the “Them” are developers, and we see them as incompetent, they will get that.  They will probably see us as being unreasonable and not able to understand the intricacies of software development. They will also act accordingly.
• Ownership: Do we have a mentality of a whole team?  Do we have a shared task that we cannot complete alone?  Is our mindset that of “I own the results”?  If not, then it is all too easy to be in an obligation mindset and do estimates a year out because “you HAVE TO”.  And if you do that, then you disconnect from the results and can easily convince yourself “well they were asking for something unreasonable anyway, so I gave it to them although I KNEW it was the wrong thing to do”.
• Intent: Why are we REALLY doing estimates?  Is it our intention to just get the managers off our backs?  Or, as managers, is our intention to hold people accountable (and even CYA?) if things go wrong even though we know estimates are a fiction?

So, if we are doing some sort of estimation method and it is not working, perhaps we need to look at the team dynamics.  Perhaps we need to look at how we work together as a team around our agreements.  And perhaps we need to look for some of those pesky invisible impediments and start on fixing them first – BEFORE we look at the estimation methods themselves.