How to estimate your tasks?

Effort estimation. That’s something what you need to do quite often if you are working as a developer. It depends on your company’s working structure and methodology how often and for how big tasks do you need to do it, but it is almost sure that you need to do it.

More and more companies are following some agile software development methodology, in this case you need to estimate only smaller tasks, or if a task would be too complex you should propose to split it into multiple tasks/subtasks.

If your project is following some classical methodology (V-model, Waterfall etc.) or you are a more experienced developer and you need to support new projects with some high level estimations, then it can happen that you need to estimate really big tasks (months/years of work).

Doing a proper estimation is not easy at all, but it is really important for the management, since they can plan the work after your estimation. So if your estimation is too low the management will still expect from you to done the work inside the estimated time. That means you will be really under pressure which is of course bad for you, so try to avoid it. Too high estimation is basically good for the developer (OK, it can be boring if you have nothing to do), but bad for the management, since they are even paying for the part of your time, which would not be really necessary for the task. That’s why managers always try to ask you to decrease your estimation. But how to do a proper estimation?

First of all try to split the task into subtasks: try to have subtasks, which are easier to estimate, like implementing one well specified functionality etc. At this step don’t forget about non-implementation tasks: technical planning (design), code review, testing (manual testing still takes some time), documentation etc.

As next step you need to estimate all the subtasks. Here always try to do it based on some similar tasks which you have already done in the past. Do not estimate your time in a way, that if you sit down and just concentrating on this then you may finish it in 4 hours, because usually it is not the case. Calculate it in the way how you are really working on a normal day: you are drinking a coffee, having a cigarette, doing some short talk with colleagues, checking your e-mails and in the meanwhile you are working on your task. Rather say: OK, I can do it in one day, with a comfortable velocity. Count always with possible bugs: maybe your first implementation won’t work as is shall and it takes some time to figure out the root cause. Or maybe you will have some issues with the version control system.

Especially if you have less experience with the task it is a good practise to do two estimations parallel by two developers, compare and discuss the results later.

One more trick: always try to work with some predefined possible estimations: like 1 hour, 2 hours, half day, one day etc., then it is easier to decide to which category does your task belong.

In the end you have a list of subtasks (to do list) with some estimations. So that if someone asks you why is it 1 week and if it could be decreased just refer to the to do list. If your manager would like to decrease the working time always propose to decrease the to do list as well, like: if I don’t implement 100% code coverage unit tests, just 50%, then I can save 2 hours on testing etc. But never decrease your estimation without changing the to do list, that looks unprofessional!

What are you tips and tricks for estimations?

I wish you a nice day and good luck at estimation!
RelaxedProgrammer