4 common mistakes developers make when estimating
June 09, 2015 - Marco Behler
So, your boss asked you to estimate a new feature. You talked a bit about that feature with your teammates. Then came silence. And a brain strain. But after a while you finally came up with your estimate of "ahem...1..to...2..days".
Wrong Buzzer Sound. Oops, wrong (again)! Turned out it took you almost a whole week to implement.
What went wrong? And what goes wrong in general when developers estimate tasks? Let's find out!
1. Reliance on Gut Feeling Alone
How would you like your doctor go: "Well, some people die with this type of surgery, some don't. I don't really know. I don't keep track. I mean, you probably will be fine, at least that is what my gut tells me."
Estimation always involves a certain amount of gut feeling. That gut feeling might get more and more accurate with experience and you might even be convinced that your gut feeling is "right" most of the time. But why not look at hard numbers instead of vague feelings?
It is a nice surprise the first time that you look back at all your estimate/actual-ratios from the last couple of months and find out what your "deviation"-factor is: If you always estimate far too optimistic (0.2x the actual effort) or pessimistic (7x the actual effort). (That deviation factor is not the only means to evaluate your past estimates/actual ratios, but a good start.)
In short the problem is to fail to regularly check up on your past estimates and find out how (un)reliable your gut really is.
2. Not Pushing Back On Vagueness or Super-Sized Features
My personal favourite: "Hey, I need a quick estimate on that new improved shopping cart".
What does that even mean? What exactly does that new, improved shopping cart feature entail? How much information is missing at the moment? What else do I need to know?
Noone can just look at a vague feature request and come up with a reliable estimate. You have to split down that feature in small tasks and work them: Asking questions, doing research.
Only then will you be able to come up with an estimate. Everything else is a look through the magic ball.
3. Succumbing to Gang Mentality and Mental Boundaries
This one can be very subtle.
It could be that your boss sets a mental boundary for your estimates by claiming prematurely that this feature "cannot take too long to implement", which might force you to be overly optimistic.
Or you are sitting in an estimation meeting with 10 other developers and you come up with a group-think estimate.
Or one of your hierarchically higher colleagues overrides your personal estimate and you simply take on his estimate instead of your own, relying on his authority.
In short: Everyone else comes up with the estimate but you, the guy implementing the feature.
4. Succumbing to Time Pressure
Proper estimation takes time, not just 5 minutes.
Sometimes a boss or client wants an immediate estimate, which is impossible except you are looking at a very specific scope which you have estimated/implemented many times before already.
Additionally you maybe have 5000 other pressing tasks to finish, so you cannot waste so much time on estimating something. Your 5 second gut feeling will do just fine!
I don't even need to tell you how reliable your estimates are going to be in that case.
Summary
We looked at common mistakes that are made when estimating. But what about solutions?
The solution almost always involves a change of mind. Pushing back on your superiors or teammates. Fighting for two-way street communication instead of just being on the receiving end of insane feature requirements.
Next Steps
You will find some articles on this blog already which help you split up and clarify requirements, as well as push back. More will follow in the next couple of weeks.
If you want to be taken more by the hand and learn how to work these feature requirements from [A-Z], also check out my upcoming book on customer requirements..
In any case, stay tuned for the next blog articles!