Software Estimation Notes

Estimating a software project is not so trivial and requires us to take some calculated approach keeping in mind certain parameters. The notes here will describe those parameters and will not write in detail about them.

1. Distinguish between estimates, targets, and commitments.
2. When you are asked about an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.
3. When you see a single point estimate, ask whether the number is an estimate or whether it’s really a target.
4. When you see a single point estimate, that number’s probability is not 100%. Ask what the probability of that number is.
5. The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.
6. Don’t provide “percentage confident” estimates (especially 90% confident) unless you have quantitatively derived basis for doing so.
7. Avoid using artifically narrow ranges. Be sure the ranges you use in your estimates don’t misrepresent your confidence in your estimates.
8. If you are feeling pressure to make your ranges narrower, verify that the pressure is actually coming from an external source and not from yourself.
9. The penalties for underestimation are more severe than the penalties of overestimation, so if you can’t estimate with complete accuracy, try to err on the side of overestimation rather than underestimation.
10. Recognize a mismatch between a project’s business target and a project’s estimate for what it is: valuable risk information that the project might not be successful. Take corrective action early, when it can do some good.
11. It isn’t possible to estimate the amount of work required to build something when that “something” has not been defined.
12. The accuracy of the software estimate depends on the level of refinement of the software’s definition.
13. The Cone of Uncertainty doesn’t narrow itself. You narrow the Cone by making decisions that remove sources of variability from the project. Some of these decisions are about what the project will deliver; some are about what the project will not deliver. If these decisions change later, the Cone will widen.
14. Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.
15. Account for the Cone of Uncertainty by having one person create the “how much” part of the estimate and a different person create the “how uncertain” part of the estimate.
16. Don’t expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can’t accurately estimate an out-of- control process. As a first step, fixing the chaos is more important than improving the estimates.
17. To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies.
18. One of the most common sources of estimation error is forgetting to include necessary tasks in the project estimates (Omitted work falls into three general categories: missing requirements, missing software- development activities, and missing non- software-development activities).
19. Include time in your estimates for stated requirements, implied requirements, and nonfunctional requirements that is, all requirements. Nothing can be built for free, and your estimates shouldn’t imply that it can.
20. On projects that last longer than a few weeks, include allowances for overhead activities such as vacations, sick days, training days, and company meetings.
21. Avoid having “control knobs” on your estimates. While control knobs might give you a feeling of better accuracy, they usually introduce subjectivity and degrade actual accuracy.
22. Don’t give off the cuff estimates. Even a 15 minute estimate will be more accurate.
23. Invest an appropriate amount of effort assessing the size of the software that will be built. The size of the software is the single most significant contributor to project effort and schedule.
24. Factor the kind of software you develop into your estimate. The kind of software you’re developing is the second-most significant contributor to project effort and schedule.
25. When choosing estimation techniques, consider what you want to estimate, the size of the project, the development stage, the project’s development style, and what accuracy you need.
26. Count if at all possible. Compute when you can’t count. Use judgement alone only as a last resort.
27. Collect historical data that allows you to compute an estimate from a count.
28. Look for something you can count that is a meaningful measure of the scope of work in your environment.
29. Don’t discount the power of simple, coarse estimation models such as average effort per defect, average effort per webpage, average effort per story, and average effort per use case.
30. Avoid using expert judgment to tweak an estimate that has been derived through computation. Such “expert judgment” usually degrades the estimate’s accuracy.