# A 100 things to consider when estimating software project cost

1. Distinguish between estimates, targets, and commitments.

2. When you’re asked to provide 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 %. Ask what the probability of that number is.

5. Don’t provide “percentage confident” estimates (especially “% confident”) unless you have a quantitatively derived basis for doing so.

6. Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates don’t misrepresent your confidence in your estimates.

7. If you are feeling pressure to make your ranges narrower, verify that the pressure actually is coming from an external source and not from yourself.

8. Don’t intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.

9. 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.

10. Many businesses value predictability more than development time, cost, or flexibility. Be sure you understand what your business values the most.

11. Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate cannot have more accuracy than is possible at your project’s current position within the Cone.

12. Don’t assume that the Cone of Uncertainty will narrow itself. You must force the Cone to narrow by removing sources of variability from your project.

13. Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.

14. 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.

15. 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.

16. To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies.

17. 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.

18. Include all necessary software-development activities in your estimates, not just coding and testing.

19. On projects that last longer than a few weeks, include allowances for overhead activities such as vacations, sick days, training days, and company meetings.

20. Don’t reduce developer estimates—they’re probably too optimistic already.

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 -minute estimate will be more accurate.

23. Match the number of significant digits in your estimate (its precision) to your estimate’s accuracy.

24. 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.

25. Don’t assume that effort scales up linearly as project size does. Effort scales up exponentially.

26. Use software estimation tools to compute the impact of diseconomies of scale.

27. If you’ve completed previous projects that are about the same size as the project you’re estimating—defined as being within a factor of from largest to smallest—you can safely use a ratio-based estimating approach, such as lines of code per staff month, to estimate your new project.

28. 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.

29. 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.

30. Count if at all possible. Compute when you can’t count. Use judgment alone only as a last resort.

31. Look for something you can count that is a meaningful measure of the scope of work in your environment.

32. Collect historical data that allows you to compute an estimate from a count.

33. Don’t discount the power of simple, coarse estimation models such as average effort per defect, average effort per Web page, average effort per story, and average effort per use case.

34. Avoid using expert judgment to tweak an estimate that has been derived through computation. Such “expert judgment” usually degrades the estimate’s accuracy

35. Use historical data as the basis for your productivity assumptions. Unlike mutual fund disclosures, your organization’s past performance really is your best indicator of future performance.

36. Use historical data to help avoid politically charged estimation discussions arising from assumptions like “My team is below average.”

37. In collecting historical data to use for estimation, start small, be sure you understand what you’re collecting, and collect the data consistently.

38. Collect a project’s historical data as soon as possible after the end of the project.

39. As a project is underway, collect historical data on a periodic basis so that you can build a data-based profile of how your projects run.

40. Use data from your current project (project data) to create highly accurate estimates for the remainder of the project.

41. Use project data or historical data rather than industry-average data to calibrate your estimates whenever possible. In addition to making your estimates more accurate, historical data will reduce variability in your estimate arising from uncertainty in the productivity assumptions.

42. If you don’t currently have historical data, begin collecting it as soon as possible.

43. To create the task-level estimates, have the people who will actually do the work create the estimates.

44. Create both Best Case and Worst Case estimates to stimulate thinking about the full range of possible outcomes.

45. Use an estimation checklist to improve your individual estimates. Develop and maintain your own personal checklist to improve your estimation accuracy.

46. Compare actual performance to estimated performance so that you can improve your individual estimates over time.

47. Decompose large estimates into small pieces so that you can take advantage of the Law of Large Numbers: the errors on the high side and the errors on the low side cancel each other out to some degree.

48. Use a generic software-project work breakdown structure (WBS) to avoid omitting common activities.

49. Use the simple standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates for estimates containing tasks or fewer.

50. Use the complex standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates when you have about tasks or more.

51. Don’t divide the range from best case to worst case by to obtain standard deviations for individual task estimates. Choose a divisor based on the accuracy of your estimation ranges.

52. Focus on making your Expected Case estimates accurate. If the individual estimates are accurate, aggregation will not create problems. If the individual estimates are not accurate, aggregation will be problematic until you find a way to make them accurate.

53. Estimate new projects by comparing them to similar past projects, preferably decomposing the estimate into at least five pieces.

54. Do not address estimation uncertainty by biasing the estimate. Address uncertainty by expressing the estimate in uncertain terms.

55. Use fuzzy logic to estimate program size in lines of code.

56. Consider using standard components as a low-effort technique to estimate size in a project’s early stages.

57. Use story points to obtain an early estimate of an iterative project’s effort and schedule that is based on data from the same project.

58. Exercise caution when calculating estimates that use numeric ratings scales. Be sure that the numeric categories in the scale actually work like numbers, not like verbal categories such as small, medium, and large.

59. Use t-shirt sizing to help nontechnical stakeholders rule features in or out while the project is in the wide part of the Cone of Uncertainty.

60. Use proxy-based techniques to estimate test cases, defects, pages of user documentation, and other quantities that are difficult to estimate directly.

61. Count whatever is easiest to count and provides the most accuracy in your environment, collect calibration data on that, and then use that data to create estimates that are well-suited to your environment.

62. Use group reviews to improve estimation accuracy.

63. Use Wideband Delphi for early-in-the-project estimates, for unfamiliar systems, and when several diverse disciplines will be involved in the project itself.

64. Use an estimation software tool to sanity-check estimates created by manual methods. Larger projects should rely more heavily on commercial estimation software.

65. Don’t treat the output of a software estimation tool as divine revelation. Sanity-check estimation tool outputs just as you would other estimates.

66. Use multiple estimation techniques, and look for convergence or spread among the results.

67. If different estimation techniques produce different results, try to find the factors that are making the results different. Continue reestimating until the different techniques produce results that converge to within about %.

68. If multiple estimates agree and the business target disagrees, trust the estimates.

69. Don’t debate the output of an estimate. Take the output as a given. Change the output only by changing the inputs and recomputing.

70. Focus on estimating size first. Then compute effort, schedule, cost, and features from the size estimate.

71. Reestimate.

72. Change from less accurate to more accurate estimation approaches as you work your way through a project.

73. When you are ready to hand out specific development task assignments, switch to bottom-up estimation.

74. When you reestimate in response to a missed deadline, base the new estimate on the project’s actual progress, not on the project’s planned progress.

75. Present your estimates in a way that allows you to tighten up your estimates as you move further into the project.

76. Communicate your plan to reestimate to other project stakeholders in advance.

77. Develop a Standardized Estimation Procedure at the organizational level; use it at the project level.

78. Coordinate your Standardized Estimation Procedure with your SDLC.

79. Review your projects’ estimates and estimation process so that you can improve the accuracy of your estimates and minimize the effort required to create them.

80. Use lines of code to estimate size, but remember both the general limitations of simple measures and the specific hazards of the LOC measure in.

81. Count function points to obtain an accurate early-in-the-project size estimate.

82. Use the Dutch Method of counting function points to attain a low-cost ballpark estimate early in the project.

83. Use GUI elements to obtain a low-effort ballpark estimate in the wide part of the Cone of Uncertainty.

84. With better estimation methods, the size estimate becomes the foundation of all other estimates. The size of the system you’re building is the single largest cost driver. Use multiple size-estimation techniques to make your size estimate accurate.

85. Use software tools based on the science of estimation to most accurately compute effort estimates from your size estimates.

86. Use industry-average effort graphs to obtain rough effort estimates in the wide part of the Cone of Uncertainty. For larger projects, remember that more powerful estimation techniques are easily cost-justified.

87. Use the ISBSG method to compute a rough effort estimate. Combine it with other methods, and look for convergence or spread among the different estimates.

88. Not all estimation methods are equal. When looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results.

89. Use the Basic Schedule Equation to estimate schedule early in medium-to-large projects.

90. Use the Informal Comparison to Past Projects formula to estimate schedule early in a small-to-large project.

91. Use Jones’s First-Order Estimation Practice to produce a low-accuracy (but very low-effort) schedule estimate early in a project.

92. Do not shorten a schedule estimate without increasing the effort estimate.

93. Do not shorten a nominal schedule more than %. In other words, keep your estimates out of the Impossible Zone.

94. Reduce costs by lengthening the schedule and conducting the project with a smaller team.

95. For medium-sized business-systems projects (, to , lines of code) avoid increasing the team size beyond people.

96. Use schedule estimation to ensure your plans are plausible. Use detailed planning to produce the final schedule.

97. Remove the results of overly generic estimation techniques from your data set before you look for convergence or spread among your estimates.

98. When allocating project effort across different activities, consider project size, project type, and the kinds of effort contained in the calibration data used to create your initial rolled-up estimate.

99. Consider your project’s size, type, and development approach in allocating schedule to different activities.

100. Use industry-average data or your historical data to estimate the number of defects your project will produce.