22.3 Using Ranges (of Any Kind)

22.3 Using Ranges (of Any Kind)

As discussed throughout this book, ranges are the most accurate way to reflect the inherent inaccuracy in estimates at various points in the Cone of Uncertainty. You can combine ranges with the other techniques described in this chapter (that is, ranges of coarse time periods, using ranges for a risk-quantified estimate instead of plus-or-minus qualifiers, and so on).

When you present an estimate as a range, consider the following questions:

• 
  

  
  What level of probability should your range include? Should it include ±1 standard deviation (68% of possible outcomes), or does the range need to be wider?

  
  


• 
  

  
  How do your company's budgeting and reporting processes deal with ranges? Be aware that companies' budgeting and reporting processes often won't accept ranges. Ranges are often simplified for reasons that have little to do with software estimation, such as "The company budgeting spreadsheet won't allow me to enter a range." Be sensitive to the restrictions your manager is working under.

  
  


• 
  

  
  Can you live with the midpoint of the range? Occasionally, a manager will simplify a range by publishing the low end of the range. More often, managers will average the high and low ends and use that if they are not allowed to use a range.

  
  


• 
  

  
  Should you present the full range or only the part of the range from the nominal estimate to the top end of the range? Projects rarely become smaller over time, and estimates tend to err on the low side. Do you really need to present the low end to high end of your estimate, or should you present only the part of the range from the nominal estimate to the high end?

  
  


• 
  

  
  Can you combine the use of ranges with other techniques? You might want to consider presenting your estimate as a range and then listing assumptions or quantified risks.

  
  

Tip #108

Use an estimate presentation style that reinforces the message you want to communicate about your estimate's accuracy.

Usefulness of Estimates Presented as Ranges

Project stakeholders might think that presenting an estimate as a wide range makes the estimate useless. What's really happening is that presentation of the estimate as a wide range accurately conveys the fact that the estimate is useless! It isn't the presentation that makes the estimate useless; it's the uncertainty in the estimate itself. You can't remove the uncertainty from an estimate by presenting it without its uncertainty. You can only ignore the uncertainty, and that's to everyone's detriment.

The two largest professional societies for software developers—the IEEE Computer Society and the Association of Computing Machinery—have jointly decided that software developers have a professional responsibility to include uncertainty in their estimates. Item 3.09 in the IEEE-CS/ACM Software Engineering Code of Ethics reads as follows:

Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. In particular, software engineers shall, as appropriate:

3.09 Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates. [emphasis added]

Including uncertainty in your estimates isn't just a nicety, in other words. It's part of a software professional's ethical responsibility.

Ranges and Commitments

Sometimes, when stakeholders push back on an estimation range, they're really pushing back on including a range in the commitment. In that case, you can present a wide estimation range and recommend that too much variability still exists in the estimate to support a meaningful commitment.

After you've reduced uncertainty enough to support a commitment, ranges are generally not an appropriate way to express the commitment. An estimation range illustrates what the nature of the commitment is—more or less risky—but the commitment itself should normally be expressed as a single-point number.

Tip #109

Don't try to express a commitment as a range. A commitment needs to be specific.