It’s no secret that most development teams hate estimation. In my own research, this is one of the most hot-button topics in the industry. You don’t need to look any further than the #noestimates hashtag / discussion on Twitter to see that many programmers & PMs would love to avoid estimation if they could help it.

One common pain point in estimation is that bosses and clients tend to take estimates as commitments. We’ve all seen scenarios like this:

MANAGER: Hey, how long do you think it would take to build that feature I was telling you about yesterday?

DEVELOPER: <feeling pressure to please boss> Um, I would say about 10 days.

MANAGER: Great, thanks! <Immediately emails clients to announce rollout of new feature in 10 days.>

What happened here? The developer unwisely threw out a single number on the fly, under pressure, and probably underestimated in order to please their boss. The boss, on the other hand, heard a specific number, unwisely considered it a guarantee or commitment, and ran with it. Nothing good comes from situations like this.

There are a couple of estimation pathologies I could talk about here, but the one I’d like to focus on is the use of an unqualified Single Point Estimate. That is an estimate consisting of a single value, usually given in time units: “3 days”, “2 weeks”, “6 months”.

What’s wrong with giving single point estimates?

• They don’t communicate a confidence level. Are you 100% confident in the estimate? 50%? 10%? A single point estimate leaves it up to the recipient to guess the confidence level.
• They often misrepresent their accuracy, by being overly precise. “14 days” sounds very precise, and could be taken as confident estimate, but it might actually be a complete guess.

Alright, single point estimates don’t communicate estimates well. What are better ways to communicate estimates? Here are a few improvements I recommend:

Provide a confidence value along with your estimate.“I’m 80% confident I can have this done in 5 days.”

Better yet, include assumptions & potential risks. “I’m 80% confident I can have this done in 5 days. That assumes we are sticking with this feature set. I’m concerned that the 3rd party API docs aren’t up to date, and that might stretch things out a bit.”

Provide a range. “I estimate 1-2 week for this feature.” You’re communicating that you’re not confident enough to provide a single number, but still providing useful information.

Make your precision match your accuracy. Instead of “19 days”, you might say “about 20 days”. You can use a less precise number to help communicate that your estimate is not 100% accurate.

The first step to improving estimates is to communicate them better. Avoid unqualified single point estimates like the plague.