4.9 Unwarranted Precision

In casual conversation, people tend to treat "accuracy" and "precision" as synonyms. But for estimation purposes, the distinctions between these two terms are critical.

Accuracy refers to how close to the real value a number is. Precision refers merely to how exact a number is. In software estimation, this amounts to how many significant digits an estimate has. A measurement can be precise without being accurate, and it can be accurate without being precise. The single digit 3 is an accurate representation of pi to one significant digit, but it is not precise. 3.37882 is a more precise representation of pi than 3 is, but it is not any more accurate.

Airline schedules are precise to the minute, but they are not very accurate. Measuring people's heights in whole meters might be accurate, but it would not be at all precise.

Table 4-5 provides examples of numbers that are accurate, precise, or both.

Table 4-5: Examples of Accuracy and Precision
Example	Comment
pi = 3	Accurate to 1 significant digit, but not precise
pi = 3.37882	Precise to 6 significant digits, but accurate only to 1 significant digit
pi = 3.14159	Both accurate and precise, to 6 significant digits
My height = 2 meters	Accurate to 1 significant digit, but not very precise
Airline flight times	Precise to the minute, but not very accurate
"This project will take 395.7 days, ± 2 months"	Highly precise, but not accurate to the precision stated
"This project will take 1 year"	Not very precise, but could be accurate
"This project will require 7,214 staff hours"	Highly precise, but probably not accurate to the precision stated
"This project will require 4 staff years "	Not very precise, but could be accurate

For software estimation purposes, the distinction between accuracy and precision is critical. Project stakeholders make assumptions about project accuracy based on the precision with which an estimate is presented. When you present an estimate of 395.7 days, stakeholders assume the estimate is accurate to 4 significant digits! The accuracy of the estimate might be better reflected by estimating 1 year, 4 quarters , or 13 months, rather than 395.7 days. Using an estimate of 395.7 days instead of 1 year is like representing pi as 3.37882—the number is more precise, but it's really less accurate.

Tip #23

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

4.10 Other Sources of Error

The sources of error described in the first nine sections of this chapter are the most common and the most significant, but they are not exhaustive. Here are some of the other ways that error can creep into an estimate:

Unfamiliar business area
Unfamiliar technology area
Incorrect conversion from estimated time to project time (for example, assuming the project team will focus on the project eight hours per day, five days per week)
Misunderstanding of statistical concepts ( especially adding together a set of "best case" estimates or a set of "worst case" estimates)
Budgeting processes that undermine effective estimation (especially those that require final budget approval in the wide part of the Cone of Uncertainty)
Having an accurate size estimate, but introducing errors when converting the size estimate to an effort estimate
Having accurate size and effort estimates, but introducing errors when converting those to a schedule estimate
Overstated savings from new development tools or methods
Simplification of the estimate as it's reported up layers of management, fed into the budgeting process, and so on