Software estimation is something that I still can’t get right all the time even after doing countless projects. Software estimation is more of an art rather than a science since it involves various fuzzy factors and not-so-fuzzy factors. But sometimes when you are asked to give a schedule for a project or for a project component. I follow these guidelines which has helped me to make my schedule estimation less inaccurate.
1. How familiar are you with the language you will be programming with? The less familiar, the more you must add more man days.
2. How well do you know the design and the various issues? The less you know, the more man days you need to add
3. How many people will be working with you on this project? The more people you have, the lesser man days you need, BUT, that doesn’t mean that if you have an army of programmers working with you. You can get the project done in 1 day.
It does not quite work that way as quoting Fred Brooks who wrote the classic “Mythical Man Month”. He said that “The bearing of a child takes nine months, no matter how many women are assigned.” So assigning more programmers will help shorten a project timeline, but beyond a certain point, the law of diminishing returns kicks in and the project timeline will be extended with more people being added to a project. It is amazing how many developers, project managers, project leaders forget this fundamental rule.
Anyway, once you have your schedule using guidelines 1,2 and 3. Multiply it by 1.5 and you can get your estimated schedule. Hey, I did mention schedule estimation is a fuzzy art, right?
Have you read Steve McConnell’s Software Estimation: Demystifying the Black Art?
Forget to bring up these 10 points
10 tips for accurate software estimates from that book:
1. Don’t intentionally underestimate. The penalty for underestimation
is worse than for overestimation.
2. Don’t provide “percentage confident” estimates unless you have a
quantitatively derived basis for doing so.
3. Don’t reduce developer estimates; they’re probably too optimistic already.
4. Invest effort in assessing the size of the software (lines of code)
that will be built. Size is the single most significant contributor to
project effort and schedule.
5. Don’t assume that effort scales up linearly as project size does.
Effort scales up exponentially.
6. Use historical data as the basis for your productivity assumptions.
7. Use data from your current project to create highly accurate
estimates for the remainder of the project.
8. For task-level estimates, have the people who will do the work
create the estimates.