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:
“What is an estimate really? Its just a guess, it could be right, it could be wrong. It’s really just a guesstimate.”
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.
Estimates as guesstimates
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.
Implying a higher degree of accuracy
How you describe your estimates is important. The units that you use can imply a certain level of accuracy.
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.
Where the best estimates come from
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 best answer…
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”
Time to read: 3 minutes
I recently watched the Movie ‘Christine’ starring Rebecca Hall (illustrated above). Based on a true story, the movie deals with issues of being a misfit, living up to the expectations that we put on ourselves and coping with it all.
There are few scenes where we are able to gain an insight into the mind of the protagonist (Christine) as she tries to solve the problems and dilemmas of life.
If you plan to watch the movie for yourself I would advise against googling ‘Christine Chubbick’ to avoid any spoilers.
Christine regularly visits a children’s hospital, and performs a sock puppet show. She sometimes finds herself talking through her own problems via the sock puppets. These are great scenes and its amazing to see how externalising problems helps in clarifying what’s bothering Christine.
The “Yes, but..” exercise
Another scene is where Christine is unknowingly coerced into an TA (Transaction Analysis) meeting. She partners up with a stranger and participates in a “Yes, but..” exercise.
You start by stating a problem: ‘My husband won’t paint the house’
The person listening would suggest a solution: ‘What if you hired a painter’
If the suggestions isn’t appropriate then you have a chance to object: ‘Yes, but i can’t afford a painter’
Another solution is suggested: ‘What if you painted the house’
The format is repeated until you arrive at a solution that is suitable. In most* cases solving the problem is completely within your control; we can make a decision or change our attitude without waiting for others to change.
*This statement is not always applicable; as an example the character Christine suffered from a mental illness.
Root cause analysis
In business the equivalent tool we have is the 5 why’s. The 5 why’s was developed within Toyota by Sakichi Toyoda. It was used to advance their manufacturing process. An example that may come straight out of Toyota:
The car wont start.
- Why =The battery is dead
- Why = The interior lights were left on for several days
- Why = The door sensor stopped working
Further to finding the root cause of a problem or failure there are ancillary benefits of using an iterative process when solving a problem. We are also able to easily identify and question Assumption and Logical Traps
Assumptions is something that we are all familiar with, but to use our earlier example, when Christine used the sock puppets. it helped her to identify and question her own assumptions; the same can be said of the ‘Yes, but..’ exercise.
On the other hand logical traps are shortcuts that our brains uses in order to make decisions faster. We do this by identifying patterns, making estimations and trying to make connections all in an effort to reduce the amount of effort that is needed to think. Logic Traps are very useful and at the same time they can be misleading and inaccurate (hence why we use the 5 why’s)
If you are using root cause analysis with a work setting, you may need to go through more than five iterations in order to find the root cause. Furthermore you may find that there is more than one point of failure.
Self examination is a good exercise to go through and a great to skill to have. It does take some level of courage to critic yourself and a level of self belief to know that in the end, you will be better for it. In business prudence is shown when you decide to be proactive and not waiting for the next ‘major incident’ to initiate root cause analysis.
In both cases problems are easier to handle and solve when they are small and not screaming out at you.