Communicating Software Estimates
Communication is hard. It's also extremely important. We're lucky that in the field of software development miscommunication tends to lead to project delays instead of loss of life.^{1} Estimates are also hard. It's challenging to produce accurate estimates in the first place, but even after a good estimate has been produced, comes the challenging work of communicating the estimates to interested parties.
There are two very common miscommunications that occur about an estimate:
 Confusion over the precision of an estimate
 Confusion between an estimate and a commitment
Precision and Distributions
Software estimates are usually presented as a single value  the expected duration of the project, i.e. "This project should take about 8 weeks". Unfortunately, estimates are more complicated than this. We usually represent an estimate as a probability distribution.^{2} Given our expected duration of 8 weeks, there are many possible probability distributions.
Different audiences can have wildly different assumptions about the underlying probability distribution when only presented with the 8 week estimate. Management and clients will often imagine something similar to the purple curve: a very narrowband of uncertainty centered neatly around the average. Engineers might imagine something like the red curve: a small chance of the project coming in early, and a very long tail of reasonably lowprobability that the project runs significantly delayed.
When communicating an estimate we need to convey a sense of the underlying probability distribution. Is it wide or narrow? Does it neatly end or does it have a long tail? Is it symmetric or rightskewed?
If you're communicating with a more technical audience, or the person reading the estimate needs to have a detailed understanding of the estimate, you have the luxury of going into significant detail to convey the shape of the probability distribution. More typically we have a very small amount of space and time to communicate this information with nontechnical users.
Below are some of our techniques for trying to concisely communicate this information. We try to compare the probability distribution someone would imagine based on the estimate with the probability distribution we're thinking of for the estimate itself.
Mention the Worst Case
Here we simply add the worstcase scenario to our estimates, to help skew someone's perception to the possibility of a longer duration.
Confidence Interval
This is similar to the way a political poll might be reported. You specify the range over which you have 90%  or another specific value  confidence that the project will complete within this range. This tends to flatten people's expectation over the entire range.
Use Only the Upper Bound
This tends to be most appropriate if there's a chance of confusion between an estaimte and a commitment (see below). This tends to skew people's perception to be significantly longer.
Give Up
This tends to be used by projects with no requirements, rapidly changing requirements, when the deadline has already been missed several times, or when you're really tired of thinking.^{3}
Is it an Estimate or a Commitment
Estimates and commitments are two different things. An estimate should be an unbiased guess at reality; a commitment is a promise to another party about the timeline for a deliverable. A commitment should be reduced to a singlevalue. You don’t make a promise that there’s a 50% chance you’ll do your work by Tuesday. You make a promise that you will do your work by Tuesday.
Since a commitment is a promise we like to be very explicit with them.
Commitments should be a date taken from the higherend of the probability distribution at the level you're most comfortable with  we usually go with 95% or 99% depending on the project.
The Most Likely Mistake
When you're communicating an estimate the most likely mistake is that the other party considers it to be a commitment. We have found an easy way to mitigate this is to deliver an estimate with an explicit commitment when possible:
There’s a 90% chance that the project is finished between 6 weeks and 16 weeks. The most likely duration is 8 weeks. If we're doing this as a fixedbid project we can commit to finishing the project in 20 weeks.
When we can't deliver a commitment with the estimate we like to explicitly state that there is no commitment being made. Ideally we can at least tell them what we need before we can make a commitment
There’s a 90% chance that the project is finished between 6 weeks and 16 weeks. The most likely duration is 8 weeks. We cannot commit to completing the project in a specific duration until the final UI designs are finalized.
Communication is hard and takes work
Most software projects run behind schedule and a big reason is the difficulty in producing accurate estimates in the first place. Another major problem is the way software estimates are communicated to decision makers.
When talking about estimates be mindful about the common mistakes that your listeners will make. What can you do to convey a more accurate sense of the estimate to them? How can you make sure they don't mistake your estimate for a commitment?
If you found this post interesting or informative I'd highly recommend Steve McConnell’s Software Estimation. Or, if you have any suggestions for better ways to communicate, please let us know @apsislabs!
Footnotes

Disasters in other industries can often be attributed to a miscommunication. The deadliest airplane crash was caused by miscommunication during takeoff at the Tenerife airport. In medicine miscommunications are a common source of error, especially in surgery. ↩

A quick refresher on probability distributions in case you haven't thought about probability in a while. If you haven’t taken any courses on statistics and probability I strongly encourage it. It’s one of the most useful mathematical tools in software engineering and daily life. Kahn Academy has a good series, and there are plenty of great courses on EdX and Coursera. ↩