in reply to Estimating Task Complexity VS Loudmouth
Here is how I provide estimates on my work.
• If I have not worked with the technology before I try to strip out everything I am familiar with and provide an estimate on that first.
• Then I do a quick assessment of how difficult the new stuff will be for me to learn. Part of that assessment is what resources I can call on if I get stuck, can I create something simple right away, and does something already exist I can use. I also try to create something using the new technology. I classify this as learning time.
• I then provide an estimate (guess) how long it will take to code the task in the new technology if had experience in it.
• Add some padding time, usually 15 – 20%.
You will be off, the chances of getting it right the first time is remote. However if you estimate a larger time than you need, it will be easier to manage the project and/or customer expectations. Studies make it clear that most projects will be under estimated so go longer than you feel you will need. As well if you are enhancing or maintaining code your productivity will be lower than if you are making new code. Typically programmers doing enhancement work are 70% as effective and maintenance programming is 25% as effective as new coding, so you will need to add padding for that.
No matter what the number is that you come up with keep your boss or client in the loop with the current estimate. They will be much more open to changes if you are open and honest with them. As well keep really accurate estimates of the time the task actually took. That way next time you will be that much closer ion your estimate.
|
|---|