Software Estimation is like looking into a crystal ball. Public domain.
Looking into Crystal Ball

Top 7 Reasons Why Your Estimates Are Not Working

Software estimation is a complex and difficult topic, and let’s face it – pretty much everyone is bad at it. No matter what sort of estimation method you use, chances are the results are not much better than fortune telling via looking into a crystal ball.

However, estimation is a skill and you can improve on the skills. By knowing what are the reasons for bad estimations, you can identify them and figure out how to get better. Let’s look at the top 7 reasons why your estimates are not as good as they can be.

1. Your customers are asking for commitments, not estimates.

When your customers ask when can you deliver a feature, they are asking for a commitment instead of just an estimate.

This is the reason behind the well known phenomenon that the earliest date you gave as an estimation became the commitment date. Yes, customers always wish things happen earlier than later.

Put yourself in the position of a customer. When you ask a waiter when the food would be ready, if the waiter said 15-30 minutes, you will start to wonder where the food is at the 15 minute mark. This is universal to all of us – we expect more from our suppliers.

It does you no good to argue with your customers that you are just giving an estimate. You must understand that from their perspective, they are not asking you to estimate. They are asking you to commit, so you must be prepared to answer as such.

2. You didn’t break the work down far enough.

No matter what method (Dev Days, Story Points, Function Points, etc) you use for estimation, the pre-requisite for an accurate estimation is to break the work down into a small enough piece for the estimation to achieve the needed accuracy.

In other words, the more you break down, the more accuracy you can achieve, and vice versa.

Of course, you might not have the time to do the breakdown. In such cases, you must resist the temptation to use the wrong precision. i.e. if you can’t break things down enough, you cannot use “days” or “hours” as a unit, and must use larger units like “weeks”, “months”, or “years”.

3. You did not incorporate the concept of uncertainty in your estimates.

Do you give estimates as a single number? i.e. 10 days? Doesn’t that sound very certain?

A better way of saying it is to use a 3-number system: my estimate is between 5-15 days, with 60% uncertainty.

Of course, your customers might object to such a number since they are looking for a commitment. This is where you point to your uncertainty and say that in order for you to be more certain, more time must be spent to analyze to reduce the certainty, and the time might be better spent to actually do the work 😉

4. You did not add enough contingency to combat Murphy’s Law.

Stuffs happen. Requirements change. Too many meetings. Production issues. Key vendor’s schedule you depend on shifted on you. The only way to ensure that these things don’t impact your estimate is to “add contingency”, or the more blunt term – padding.

Are you 2x your initial estimates? You might find that’s still not enough. Yes, there are a lot of things that can happen on a non-trivial project.

5. You did not re-estimate as new information surface.

We all know our initial estimates were just rough, but what do we do with it? We assume it’s the perfect estimate and use that to plan, and lock the plan up.

No wonder customers will hold you to the commitment – they’ve only ever receive a single version of the estimate.

If you want to buck that trend, then you’ll need to re-estimate as information are discovered.

6. You did not communicate changes back to stakeholders as they arise.

If you did not re-estimate, chances are that you also didn’t communicate changes from delivery perspective back to your estimate holder either.

Yeah, usually there is some sort of Red / Yellow / Green communication that said whether the project plan is in jeopardy. But that still assumes the original estimates were the “golden copy” in the first place. If instead, the communicate on the changes were about how the estimates themselves have changed, wouldn’t it be clearer that the original plan was also an estimation?

7. You did not track the actuals for the purpose of improving your estimation skills.

Assuming you want to get better at estimating – how can you get better if you don’t know how to objectively measure your results in the first place?

In other words, if your estimate was 8 hours for a task, how do we know whether it’s good or not, unless you know how much time you end up spending on the task?

Yes – you’ll need to track the actual time spent for you to know that. How many people actually track hours these days?

Leave a reply

Your email address will not be published. Required fields are marked *