Estimates can be one of the hardest things to create as a developer. The word estimate is a misnomer in our industry. It’s almost as if they should be called “agreements” or “promises” according to some bosses. Yet we all know that they are just that: an estimate of the amount of time, not a guarantee.
Estimates can also be toxic. If you continually come in under estimate, some project managers will start to shrink your estimates without telling you. Then, the time that you really do need that estimated time, those outside of the programmers group will think you went over. The opposite is also true: go over your estimate continually, and you may be judged as a bad performer.
So, it is very important to get your estimates right. So, how do we do this?
I follow three steps when estimating: Preliminary research, Planning, and Saying no.
If you want to become a great estimator, there is no magical way to do this but to know how long it takes you to do something. That’s the advice everyone gives… if you want to estimate, look at last time you did XYZ feature and use that as a guide. But what if you haven’t had to submit an estimate for that style of feature before?
How easy is it to just pump out a block of code or a feature on your software with no timelimit or timeline? Let me tell you - it is VERY easy and also VERY great. It feels awesome to accomplish a task without a marketing, business, or even arbitrary limitation of time. However, if you find yourself with this good fortune, do not rest!
Instead, always estimate all of your tasks even if you’re not required to submit one. Then, track your time and at the end of the project compare your totals. This research is yours and yours alone. You will learn to become a better estimator and know your skill-set and timelines best this way.
When I create an estimate, I try to break down the tasks into hours/days measurements. I don’t quote anything less than 2 to 4 hours. Anything over 2 weeks, I find a way to break that up into subtasks. This planning gives me a good handle on how my project will run. It also serves as a sort of road map.
Now, be honest: how many times have you thought a task will be done “in no time” but it actually took half the day? That’s where this second tip for planning comes in. We tend to estimate less time than is needed. Call it ignorance, hubris, or superman complex, but it happens. So, when I plan my tasks, I make three columns. The first is my estimate. The second is + 20% - and is labeled ‘probable’ and the third is 40% and labeled ‘worst case.’ When I submit my estimate, I always submit a combination of the probable and worst case. Oh, and finally, I always figure in a 20% unknown into the totals as well. So at the end of the first column, add those totals up and take 20% of that total and add it to the grand total. That of course gets expanded as the columns move to the right.
The great tool here is that we often understimate - and the 20% column USUALLY covers that. However, I like to look at those numbers during/after the project and use those to learn to refactor my estimates for the future. If I’m consistently in “worst case” column, something is going wrong!
Just say No
Or, … slap “scope creep.” It can be really hard to say no to a boss or a project manager when they ask for more features. But, I implore you: for the sanity of your estimation scores and your reputation, say no. Say no respectfully. Say no with facts. But say no. Do not let additional things get in there.
However, sometimes its unavoidable. Whatever happens, put a number on that ‘yes’. That extra work doesn’t come cheap. You didn’t estimate it. Give an off-the-cuff estimate addition. “Yes, I will do what you want, even though it wasn’t part of my original plan. It will add on approximately 3 hours. Are you ok with this?” And make sure to document this!
Good luck! Estimation is not a science. But I can tell you, after many years of this, if you really pay attention to your skills and speed, you’ll get a good idea of what you can do and how long it will take you.