In Mike Cohn's book Agile Estimating and Planning there is a chapter entitled "Why Planning Fails" which cites estimates becoming commitments as one key reason for this.

He only writes 1/2 a page on the subject but understanding this is critical to the success of a customer supplier relationship in any software project. Its a trap that all development teams need discipline to avoid but most fall into it every time. The customer is keen to know when their software will be delivered so they're looking for a commitment. The development team must resist the pressure to make a commitment and instead set some expectation.

I say set some expectation because setting one expectation is the same as making a commitment. So, how can some expectations be set?

Having estimated the work, simply adding up all the estimates and pointing to a day in the calendar is easy to do and easy to communicate, but is fraught with danger. In theory an estimate by its very nature contains an element of probability and most estimates are just as likely to be accurate as not. This makes their probability 50%. In order to make a commitment the estimate probability would need to be 100%. However in practice with an highly experienced team estimates probability should be higher; more than 50% probability but still less than 100% - but its still likely that the average accuracy is 50% over the whole project.

Knowing this suggests that just adding the estimates up an pointing to a date is cheating the development team and a little unfair on the customer, because the worst case is that on average the estimates probabilities are 50% which means this date is likely to be wrong, or at least just as likely to be wrong as right.

A useful mechanism for dealing with this is to ask the team for 2 estimates one average estimate and one worst case estimate then calculate 2 standard deviations against the 2 sets of estimates. Take this value and add it into the schedule on top of all the estimates to create a buffer and set some expectation by stating that the earliest the work can be completed is at the beginning of the buffer but that it is more likely to complete at the end. To support this make sure that when the developers express a large delta between average and worst case estimates that they articulate why that exists - thus explaining to the customer why there is a risk.

Its also a good idea to adapt planning poker by giving the team 2 sets of cards and ask them to play 2 in each round - they need 2 packs because sometimes confidence is high enough to play the same card for average and worst case estimates. Finally, be careful not to confuse probability and accuracy - when and estimate is known but the work isn't started we can talk about its probability - its not until the work is complete that we know anything about its accuracy.