anchor.diff:  ==== [pattern]#Estimate in Interval#
   ===== Intent
   Estimation is a guess, not a *measurement*.
  -Estimates are uncertain, otherwise they would be observations (or measurements!).
  +Estimates are uncertain, otherwise, they would be observations (or measurements!).
   
   ===== Description
   Therefore, estimate in intervals, giving a lower and upper bound to your estimate. The difference between the two shows your confidence in the estimate. If this difference is relatively small, it shows high confidence.
  
positive.code: for parameters  | if every developer is
  concerned by the problem, we count their number.
  
  | Interval   | see <<Estimate-In-Interval>> | between 15 and 25%
  
  |===
  
  
negative.code: ==== [pattern]#Estimate Issue Cost#
  
  ===== Intent
  Find out how much a given issue costs in units of money or effort in a period or for every occurrence.
  
  ===== Description
  _Finding out_ the cost of an issue usually requires estimation or guessing, so there are
  uncertainty and probability involved.
  
  For example, if a server needs to be rebooted once every 24hrs and an operator needs 30 minutes to perform this reboot (and corresponding activities), then you can approximate the cost of this problem for, let's say, a month:
  
  5 workdays × 4 weeks × 30 min = 10hrs of operator's effort.
  
  If you multiply with (an approximated or averaged) wage, you get _problem cost_.
  
  * If possible, try to _measure_ or observe instead of guessing or estimating.
  * If you cannot determine real numbers, and you need to guess, estimate or approximate, use <<Explicit-Assumption>>. 
  
  ===== Related Practices
  
  