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 in your view you should propose to split it into multiple tasks/subtasks.
If your project is following some classica 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 managment, since they can plan the work after your estimation. So if your estimation is to low the managment 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 if basically good for the developer (ok, it can be boring if you have nothing to do), but bad for the managment, since they are even paying for the part of your time, which would not be really neccesary for the task. That’s why managers always trying 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 funtionality 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 same similar task which you already performed in the past. Do not estimate you time in a way, that if I sit down and just concentrating on this then I may finish it in 4 hours, because usualy it is not the case. Calculate with the way how you are working on a normal day: you are drinking a coffée, 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 a task it is good practice to do two estimations parallel by two developers and compare and discuss the results later on.
On 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 todo list. If your manager would like to decrease the working time always propose to decrease the todo 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!
Best regards:
RelaxedProgrammer
http://howtosurviveasaprogrammer.blogspot.com/
Top comments (0)