| I appreciate more attention being given to software estimates, but it seems like there's a lack of looking at the research in this area of software engineering. Most people have a single hocus-pocus equation that generates numbers they find convincing. Furthermore, it's often the case that these numbers are never changed over the life of the project. That would be like predicting the weather with a single model, once, for the next three months. Of course that isn't going to work. There are a few key points I think are often overlooked: * Estimating is less about understanding time, and more about sizing a project and effort -- a study in software economics. * Bottom-up estimates need to be based on historical performance. They should always be ranges and should include a notion of confidence. They should be democratically created if you're estimating for a team. You can do something simple (like Estimatr) or use a tool with a lot of data behind it (like Personal Software Process) - I do both. * Top-down estimates should also be used. I often use COCOMO and COSYSMO, with monte carlo risk calculations (http://csse.usc.edu/tools/COCOMOII.php). * The two approaches will give you two answers (both in ranges), with confidence intervals, which provides you a better sense of the size of the effort. * Generating and publishing an estimate has a psychological effect on the team - consider that wisely (read Peopleware). * Estimates are good for about two weeks, after that, they've become stale. * You're not done with a project until you've recorded your performance data (for future bottom-up estimates). * If a project is going to last three months or less, the research shows that nothing matters at all -- estimates, process, etc. -- do whatever keeps you/the team motivated. |