Estimation Deadly Sins

I came across a presentation by Steve McConnel about "The 10 Deadly Sins of Software Estimation" (also found here, if you don't want to register with Construx.)

The presentation actually goes through a list of 20 estimations sins, grouped in two levels of "fatality". Some points of notice:

• Estimating how long "“it" will take to build before anyone knows what "it" is
• Creating an estimate for a new project by comparing it to a past project which overran its estimates or ran massive overtime (i.e. using experience but not learning from it)
• Being unaware asymmetries during schedule negotiations (young, introverted developers vs. more senior, extrovert managers and marketing people)
  
• Confusing "making an estimate" with "figuring out the way to meet a target"

The presentation also includes the following quote by Tom DeMarco:

[The common definition of estimate is] ‘"An estimate is the most optimistic prediction that has a non-zero probability of coming true"

Tim Ottinger also pointed out that quote in his blog this week, adding the following advise as a way to know if that's the actual definition being used for a project:

Ask what the likelihood is of being done 15% early, and see how the estimators respond.