Giving good time estimates on software projects, new features or even on a seemingly 'minor' bug fix is hard. Very hard even. There are many depending factors like, the programmer's skillset, their knowledge about the system. But also, have you slept enough? What day is it? Do you like the project you're working on?
Project management methods and frameworks like SCRUM, Extreme Programming and KANBAN tried to give people in the industry tools for better estimations. Every developer might have seen things like planning poker, voting systems or affinity grouping. Some might even work with simple formulas that increase or decrease the number of estimated hours by a certain factor.
But enough about the struggles or techniques that can be used. Down the line these tools are designed to give some form guidance. And that's not what this article is about. Below are some personal guidlines and tips from the field to avoid commonly made mistakes before using these tools to make estimations.
Give your estimations time.
Give an estimation on your estimation and give yourself time. This is not only true for new projects or features but also on ostensibly small changes. When budgets are tight and hours short, developers tend to give estimations on the fly. This especially accounts for the seemingly trivial small changes which, most of the time, are bug fixes. Day by day you're already working on some project and need to get things done therefore it's easy to forget about peripheral matters. What seems like a minor change can work on so many levels you didn't consider when handing out an estimations in 5 seconds.
As a rule of thumb multiply your gut feeling estimated hours/days with a certain factor you feel comfortable with to reevaluate your first estimate. This depends on how experienced your are, not only in knowledge but also on the project itself.
Example: you think a bug fix will take you 2 hours to fix. With your current skillset and knowledge on the project you'll work with a factor of 10%. So give yourself at least 12 minutes (120min*0.10) to reconsider things. Open your IDE of choice, scan the code, maybe talk to one of your colleagues or team members if they have time.
Give an estimation on your estimation and give yourself time
Consult your peers.
Whether you're working on something small or large, it's always a good idea to talk with peers. The old saying "two heads are better than one" is simply true. Contrive a good solution and introduce it to one of your team members.
Something on bug fixing.
Never ever consider a bug or defect as something minor. Once a bug appears in the system it means you've made a mistake somewehere. Something is not well thought out, the logic doesn't add up. In this case, don't only account for the actual fixing time but take some time to evaluate. How did this happen? Could the same issue appear somewhere else in the system in the future? Can we make improvements to make the code more solid.
There's alway a first gut feeling when dealing with estimations
Know what you don't know.
Don't just only count in your development time. Most of the time the following is true:
- You think you know too LITTLE of the project and therefore tend to OVERESTIMATE.
- You think you know too MUCH of the project and therefore tend to UNDERESTIMATE.
By the way, it could be the exact same way around too.
Always keep in mind there will be stuff you don't know about. Some of them will surface as a bug in the future, some will remain covert forever.
The core concepts of the points above are based upon the fact that there's alway a first gut feeling when dealing with estimations. Think about how you can avoid common pitfalls before using any tools or guidelines since most estimations need to be given without them.