Your estimates are probably wrong, but you should do them anyway
We have all been there: There is so much task left at the end of the time. Why is that ? And if this is usually the case, why do we even bother estimating in the first place?
Table of Contents
Why estimates are wrong
Whenever I look back on a task that took longer than expected, the usual reason it went over the estimates is “Something unexpected came up that changed everything”. Shit happens, there is not much you can do about it, and, when it happens, it typically makes a dent in your timeline.
The second common reason I find is that something changed. This falls into two major categories: something new needed to be done or something needed to be redone. The first one has a name, it’s scope creep. It’s only natural for people to change their minds, to make just a tiny little change to the ticket. The second one can be chucked to miscommunication. This can be either from the person who made the request confusing, or the person who wrote the ticket, or the person who read the ticket and decided what should be done.
Or perhaps the task is too big. Large tasks are hard to estimate. It makes sense in the end: with bigger tasks, more pieces need to fit together. More pieces need to fit together, more room for error when estimating. And the fact that we are optimistic by nature doesn’t help. We hope things will work out in the end, so we tend to underestimate the work involved. Basically, the bigger the task, the bigger the error.
And finally, something that sometimes slips my mind, despite how obvious it is. There is only one of me. Often when I estimate a task, I image myself doing it. It’s only natural, after all, I know myself best. The problem is that there is only one me. Everyone else is different, some developers work faster, some work slower. Maybe some know a bit more about the project, while others are just starting.
Why do it then
If we know we’re not going to hit our mark, is there any reason to do it? We have the reasons why estimates are messed up, now it’s time for the good news.
Firstly, estimating forces you to look closely at what you’re building. It’s impossible to estimate something you know nothing about, so at the very least you have to look at the scope. You should be somewhat comfortable with the tech stack and consider the risks at least as a passing thought.
Secondly, it reveals your degree of certainty in the estimates. How sure am I that the timeline I provided is accurate? If the answer is not so sure, then I have to think about the reasons I’m not sure in more depth. Congratulations! You just stumbled across my risk backlog!
Thirdly, but certainly not lastly, I get to improve. Isn’t that awesome?! If I just pay attention. Whenever I don’t hit my estimates, I try not to look away. Don’t try and hide that and toss it under the rug. I look at how it happened. Was there something wrong with the initial plan? What did I miss? With time, some recurring themes appear. And then I can start looking at fixing them. Repeat and I promise you will become a better developer with time.
Conclusion
Providing estimates comes with the territory. It’s only natural to want to know when the thing you care about a lot, and have asked for, will be ready. And the internet is full of memes in which estimating did not go as planned.
It’s not all doom and gloom, though. There is a lot of value even in the simple act of estimating. The results give so much more than just the time when the work will be done. Even more so, the process of trying to get to an estimate, will make you a better developer. So don’t give up just yet. Ask “How long is this going to take?”. Even if the answer is you get is wrong, the road you take in search for a solution, will be so valuable, that it’s almost worth being wrong.