How to give accurate software estimates on-the-fly

Especially in early-stage startups, expectations are high, time is short, and funding is limited--that's why we create software estimates: to help steer the project.

The problem comes when our time estimates are way off--sometimes by a factor of 3 or 4! Deadlines are missed, frustrations are inflamed, and our own sense of worth is called into question.

In this blog post, I'll give you a simple mathematical formula you can use to create accurate software estimates, even when the full scope of work is not known ahead of time.

The napkin estimate: a system for harsh consequences and broken promises

The most common type of estimate that I see in the wild is called "The Napkin Estimate"--named so because it's done at random, in front of other people at an important meeting, and under pressure.

It's said to be "written on a napkin" because it should be regarded as crude, disposable, and inaccurate--the problem is, I rarely see it being offered that way, and it's often presented as if it were a valid estimate.

The silence at the dinner party: how a Napkin Estimate happens

Picture this: you're a software engineer at an important planning meeting with engineers, product stakeholders, and sales people, who all want to align on a particular date. A cool idea for a feature is floated, and then the Head Honcho turns to you and asks the Forbidden Question:

"How long would it take to do The Feature?"

Everyone turns to look at you--some of the eyes are pleading, some of them hopeful, others judging, but your fate for the next 3 months is determined by what comes out of your mouth next.

-- Phase 1 --

Your eyes look up and to the right, you say "Mmmmmm.....", and the following thoughts race through your mind:

"That's a trivial feature, which should be easy"
"We can just connect X to Y, and then just insert step Z into the workflow"
"That's kinda like another feature I've made, which I could implement now in X weeks"
"... I'm gonna quote X weeks!"

You feel hopeful, like a ray of sunshine!

-- Phase 2 --

But then the hope quickly disappears, as you become aware of a sinking feeling in your gut:

"..... wait, the description of the feature is missing specific details"
"... the interaction points between other features haven't been mapped out, and probably aren't known"
"... I don't even know which questions I'd need to ask, and it's likely that nobody in this room could answer them"

-- Phase 3 --

Time passes, and the silence becomes uncomfortable. You say "Ummmmm....", and stare off into space:

"everyone is looking at me"
"I have no idea what to quote"
"If I quote too high, then I'll disappoint them and ruin their plans"
"If I quote too high, I'll look stupid in front of my other engineers and managers"
"... I'm gonna quote weeks, and deal with the consequences later"

You quote X weeks, and the uneasy silence fades away, as the rest of the team happily goes on planning, satisfied with your quick napkin estimate.

The bill comes due: the consequences of the napkin estimate

X weeks have happily passes, except The Feature is not done--it's not even close to being done:

you do overtime, and force your team to do overtime
you constantly quote "one more week" every time the stakeholders ask you for a status update
in order to meet the agreed-upon time deadline, you release a half-finished feature, which is unusable, hated by the users, and creates lots of technical clean-up work and backwards-compatibility concerns

When you do a post-mortem on this feature, after you add up all the hours of planning, overtime, and the fact that the feature wasn't complete, and still needed work after it's release, you discover that it was off by a factor of 3:

in other words, if you quoted three weeks to finish The Feature, it would have taken you over two months
There are a couple alternatives out of this self-inflicted misery, which I'll cover in later blog posts. But for now, we'll focus on the napkin estimate itself, and how to turn it into something good.

Short-circuiting the napkin estimate: catching it is solving it
The critical moment of a napkin estimate comes at the beginning of Phase 2, which will be signaled by your body:
eyes moving down
feeling a sinking feeling in your stomach
feeling a sick feeling at the back of your throat, like it's difficult to speak
automatically vocalizing "Ummmm....." or another non-word sound

Any of these tells are your body's way of communicating to you, "I'm being forced into an uncomfortable situation, and I feel afraid".

Right now, if you're thinking "Yes, I've felt that before!", you can move on to the next section.

On the other hand, if you can't recall ever feeling any of these things, I recommend you pause right now and Google "The Science of Enlightenment", "contemplative prayer", or whatever you use for inner work--once you become aware of the napkin estimate, you can fix it.

Thwarting the napkin estimate with math, and accepting difficult realities

Alright--you've been waiting for it, and now I'm revealing the grand plan of how to defeat the napkin estimate, and make it useful:

multiply it by three, and quote a range

That's it.

I know that's unbelievable, but I've seen that 3x figure be accurate across companies, dev teams, and tech stacks--the human brain will consistently under-estimate the time it takes to complete a software project by a factor of three.
For example, if you think it'll take 3 weeks to complete, say "best-case three weeks, worst-case 9 weeks".

However, after you give such a wide-ranging estimate, you'll trade glances of shock, annoyance, and sadness with your peers--now is the time for you to shine as an engineer, by revealing the limits of what is, and is not known about The Feature:

you don't know the full scope of work, in every detail
you don't know how these details will interact with existing features
you don't know what parts of the work will require new infrastructure
you don't know what will happen with your labor, while the feature is being built
you don't know what will happen with business logic changes, as new details are discovered
the actual time-to-complete is wildly variable
... and you don't know what you don't know

If the group is reluctant to accept my assessment of the situation, I'll often respond with calibrated questions to point out specific areas of uncertainty

"What should happen if there is an error in Process A of The Feature?"
"What should we do, if we discover new infrastructure is needed for The Feature? This will push back the estimate."
"What if Assumption X turns out not to be true?"

These questions are an art in themselves, which you can refine over time, but the main technique is really just quoting the 3x variance and acknowledging that you can't see into the future.

When a 3x range isn't good enough

Usually, an estimate with a 3x variance won't make anybody happy, so stand your ground, and explain the above points.

On the other, certain features do require a more accurate estimate, and this is simply a fact of life.

Luckily, there are many alternatives to the Napkin Estimate, which I'll explain in future blog posts.

Summary

train yourself to listen to cues from your body, when you've been put on the spot
quote a range that is three time larger than what you think it'll take
respond to disappointment by asking calibrated questions or simply acknowledging uncertainty that you can't see in the future

Even if this doesn't make a great estimate, it'll make a safe estimate, and you can continue to flesh it out from here.

Resources

The Science of Enlightenment by Shinzen Young: meditation techniques to improve your awareness of tells your body is sending you
Never Split the Difference by Chris Voss: techniques to ask calibrated questions, which you can use to help your team accept difficult realities