About the series
This is the first part of a series of posts dedicated to talk about the biggest fears that we face as developers. Since that list can be huge, I'm not limiting it to a fixed number of parts and instead will let it grow as I get new ideas and suggestions.
Why are we (or think we are) so bad at it?
There seems to be a consensus out there that agrees on the fact that we're bad when it comes to estimations. I don't think I know a developer that has never underestimated/overestimated a task. Don't worry, you're not alone.
However, when you hear all those stories, there are some common factors that could help us understand why the estimations were so wrong. Let's see some of them.
Unknowns
Ideally, when you are going to estimate a new task, you will be provided with a detailed description of the requirements and scope. But let's face it, this is not an ideal world, and sometimes people are not clear about what they want but they still want to have an estimate.
When this happens, you need to understand that you can just give them a quick guess based on the few info provided and the previous experience you have. But that it won't be, by no means, an estimate and it's pretty sure that it's gonna change.
Confidence
No matter if it's under-confidence or overconfidence, this is an issue when trying to estimate things. Sometimes, developers tend to think that we can just sit and finish that task fast and clean and this can lead to underestimations. On the other hand, some developers don't trust their skills and usually overestimate tasks even if they're simple.
Pressure
This could be 2 things:
Internal: developers can feel the need to demonstrate that they're good at their work, and that includes estimations.
External: pressure can also come from people above us and, to be honest, that's most of the time.
Either if it's internal or external, we shouldn't let it to affect us. The truth is that it's ok not to know, and that we shouldn't give unreal estimates just to make us look good or to make people above happy.
Then, what can we do?
Don't worry, not all is lost. Here are some things that might help you to improve your estimates.
Choose an estimation technique
These are usually given by the company. In my case, we use the Fibonacci scale to estimate tickets.
Regardless the technique you use, the best thing you can do is estimate using ranges instead of explicit dates/times. This will give you some error margin to work with.
Break task
If a task is too big to estimate, it probably can be broken into smaller tasks. Defining what's big depends on each organization/team, in my case a task can't be higher than 8 on Fibonacci scale.
Spikes are your friends
I don't know what's your case but, to me, spikes are present on almost every development iteration.
And I have to say that they are super useful. Spikes bring clarity on how to approach a specific problem. Either if it's to create a small proof of concept or documenting a flow in the code, once you're done with it you will have a better understanding of what is involved on solving a problem.
What can we learn from all this?
We're not alone, this is something that every single developer has to face at some point in their career. But most importantly, it's not (always) your fault. Estimates involve a lot of stuff, including external factors that sometimes we can't control.
Have you ever been on a similar position? How do you deal with estimations? Tell us! We would love to hear about it and learn from it.
Top comments (3)
Good article! I find estimating how long a task takes really one of the hardest things in programming, especially if the task involves some areas that I'm not 100% confident about. I have found that giving a range works pretty well.
Both Time and Money.
Very good series! I could explain several anecdotes on each of the points :D
Another difficult topic, which is very closely tied to estimations is : "say no"