Time to Read: 3 mins

Early on in my career, I was asked to give an estimate on how long it would take to implement a new feature.

Now this was my first ‘real’ job out of university and to be honest I really had no idea on how to estimate.  In an attempt to assuage my discomfort (and try to get some sort of a useful response out of me) my manager added:

As I progressed further on into my work career, the term ‘guesstimate’ was something that never really sat well with me.  I recently read The Pragmatic Programmer by Andrew Hunt, in which a small chapter was dedicated on how to best handle estimations.

A guesstimate implies that there is very little science, process or calculation around making an estimate. And although a guesstimate is sometimes analogous with estimates, providing a guesstimate is not the most appropriate response in all circumstances.

A guesstimate may be appropriate when someone asks ‘when will you be free for lunch’.  In this scenario the worst case is that you end up having lunch by yourself or maybe reschedule for another day.

But if you are working on something a little more serious then a guesstimate may be ill-suited.  Let’s say you were on the Waymo project and developing self driving cars. My assumption is that they are not working off guesstimates.  Mis-interpreting distance, moving objects or road signs would have dire consequences.  In this scenario accuracy is paramount therefore a rigorous estimation approach would be more appropriate.

The point is: How much effort is taken should be dependent on the context.  The more important the context, then the more time and you should be with your estimates.

Going back to my opening example, if I gave an estimate of around 6 months to implement the new feature.  That sounds fine, right?

But if I gave my answer in days i.e. 120 days, which estimate sounds more accurate: 6 months or 120 days?

Using days assumes a more accurate estimation than months, but in some cases you don’t want to be accurate. If I was one month off the original estimate, it still doesn’t sound as bad as being 20 working days off.

Below is a general guide of giving out estimates and which units to use:

> 4 hours =  use days.

> 15 days = use weeks.

> 8 weeks = use months.

> 6 months =  take some more time to think.

The best estimates come from work that has already been done before.  If someone has completed the same or a similiar job in the past, a real world example would be the best guide in giving an accurate estimation.  If this is not available then there are other strategies that you can adopt to give a more confident and accurate estimation.

Breaking down a task into smaller components will truly give you a better understanding on what needs to be done. This process is often referred to as functional decomposition. Once you have decomposed a larger task into smaller components, you can then estimate on each component and sum the value of every component giving you a final number.

Functional decomposition will allow you to identify any dependencies between tasks that might cause your estimates to creep up.  Another benefit is that it enables you to pin point exactly where your estimates went over or under.  Having the ability to communicate that kind of information gives stakeholders a level of transparency that goes a long way to demonstrate your analysis skills.

For some professionals estimating is a regular and vital part of their job.  If this is the case try to keep a historical record on your original estimates versus the actual. Doing this over time will increase the accuracy of your estimates.  You will be able to recognise patterns and add the right contingency and tune your estimation process.

The next time you are asked for an estimate, consider the context and if it deserves something better that a guesstimate,  maybe the best response you can give is: “I’ll get back to you on that”