Uncharted Waters

Dec 19 2016   12:51PM GMT

How to Estimate Anything

Matt Heusser Matt Heusser Profile: Matt Heusser

Project management

How to EstimateSeveral years ago, (so many I can’t find the original blog post, even here), I claimed that because of the amount of unknowns, creating a real estimate was impossible. My friend Ben Simo left a comment, saying “Two Weeks.”

I guess I didn’t say it had to be accurate.

Tom Demarco once claimed the way most estimation is done is to guess a number just hard enough that the technical team is scared, but not aggressive enough that they laugh at you. If they breathe a sigh of relief, DeMarco suggested that [bad] management can find some emergency reason to make the dates more aggressive.

Here’s the kicker: Most organizations can see a massive increase in prediction accuracy using a technique I call the Heusser Estimation method – a method I’m willing to give away, on my blog, for free, right now.


This method is not universal. It applies in certain contexts. Luckily those context match nearly every single project I have worked on in my entire career. Here goes:

  1. The project’s requirements are … squiffy. You don’t know exactly what you’ll build; the customer will elaborate on the requirements during the project. For example: Even if you have “complete” requirements, they say things like “handles errors appropriately”, but don’t say what the pop-up error message will be. Surprise! The customer wants you to pause for 30 seconds, resubmit the job, then email operations if it fails — not pop-up an error.

b)   The project itself will change, as either the business environment changes or the customer sees the software in progress and responds emotionally, saying something like this: “Well, that is exactly what we asked for, but now that we see it … we know what we really need.”

This is where the “impossible to estimate” claim came from. We don’t know how long it will take because no one knows what it even is.

And yet …

… and yet …

Let’s do it anyway.

The Heusser Estimation Method

screen-shot-2016-12-19-at-11-46-47-amSince things will change, just ask “what’s my budget” … the run until the budget is gone. Assume, for example, that you are giving six months, or a budget of $240,000. Given that, divide by Sprint length (2 weeks) or cost per sprint ($20,000) and you know how many sprints you’ve got. Each sprint, if not more often, you deliver working software and allow the customer to adjust. At the end of a twelve sprint contract, the customer can extend or call the work done. My company, Excelon Development, executed fourteen contracts in 2016 using this method.

Notice this fails if the budget is wildly out of whack; no one is going to the moon with a team of ten people in two weeks. Some projects, such as an ERP upgrade, are very hard to half-do – yet for all of those, I have always found a good team can break down the project into chunks and show running, tested features often enough for the decision makers to realize three months for the upgrade was naive. Some times, the customer needs to see how things are going themselves, so they can decide the team won’t make it — and the team can provide options abut what to do instead.

Sometimes you can do better better than that. Historical data is one way to do better. For example, get a list of projects, by person-months of effort, ideally with the same team-size.

Project A – 25 person-months, 5 person team

Project B – 30 person-months, 5 person team

Project C – 45 person-months, 5 person team

Look at the next project. How “big” is it? Somewhere between A and B? Plan for 30 person-months. Boom. Done.

In my experience, these sorts of “bigger than a bread box, smaller than a fire truck” estimates tend to be as accurate as classic functional decomposition, where we break everything down into small pieces, then add it back up again. That’s because we tend to estimate in terms of perfect person-days, if everything goes right, what DeMaro and Lister call “the nano-percent date” – the point where our percent chance of success moves from 0% to slightly-more-than-zero-percent.

We can do better still.

Historical Throughput

Estimate using Yesterday's WeatherTeams tend to use velocity, with points, to track performance. If the stories are roughly the same size, or even close, I find you can typically count stories. Tracking velocity over time, most people use average of velocity to predict performance. Except, of course, if you use averages for planning you’ll be wrong half the time.

Because that is how math works.

Troy Magennis, of focused objective, suggests a different method: Use a confidence interval.

Get a list of the recent sprint performance (say ten sprints) and sort by performance. The work remaining divided by the worst performance gives us a 95% confidence interval. For 90%, average the performance of the worst two sprints. For 85%, use the worst three. All the way down to average of all of them, which is 50% confidence, because again, that’s how math works. For less confidence, average the best nine sprints (45%), the best eight (40%), the best seven (35%), and so on.

Here’s the thing: Don’t give senior management, or the customer, a date at all. Let them take the date they have in mind, and look at the percentage, and adjust it. If they ask for advice, suggest the 60 to 70% confidence range.

Don’t worry, I’ll deal with the rough edges in a follow up post. We can get into histograms and the Weibull Curve and what to do if you don’t know the number of stories and Christmas and Spring break skews the numbers … don’t worry. In the mean time, tell me why I’m wrong in the comments. This will be fun.

Thinking About Estimates: The Past Through Tomorrow

Twenty-five years ago I was a military cadet in the Frederick Composite Squadron of the Civil Air Patrol. Hanging in the case office was a sign put their by some unknown cadet officer before my time, which read:

“We the willing,

Led by the unknowing,

Have been doing the impossible,

For the Ungrateful.

We have been doing so much,

For So Long,

With So Little,

That we are now qualified to do anything for nothing.”

While that quote is not strictly true, the spirit — the we will walk gallantly and properly in the face of time pressure, uncertainty, and ambiguity — is the heart of the Heusser Estimation Method.

Go Forth and Be Awesome.

4  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • StevePoling
    Keep a couple Dungeons and Dragons dice in your desk. Toss them in your manager's presence when he asks for a ridiculous estimate.
    0 pointsBadges:
  • bmfb1980
    Meh. I'll estimate this works 62% of the time.

    Seriously, estimates are only as good as the quality/sanity/skill of those making the decisions for the target process. This is the one instance where micromanagement is actually useful... meaning if you don't have constant feedback with the user and management, your efforts might all be in vain.

    None of this would be a problem if people actually paid attention in English and science classes way back in high school. Now add foreign-educated people who's native language is not English into the mix... and well, you have what we have now. A complete mess, where the final cost is always passed on to the consumer in the end.

    Is this why prices always keep creeping up for everything? :)
    70 pointsBadges:
  • BradleyRoss
    The way to see an increase in accuracy is for management to realize that estimates are supposed to be accurate. If they are actually accurate, half the projects will be above estimate and half will be below estimate. If management requires that all projects come in twenty percent below budget, the estimates are by definition wrong.

    The secret of rocket science is that there is no secret. It's just that everything has to work and there are no short-cuts.
    60 pointsBadges:
  • bmfb1980
    Aha Bradley... you've stumbled upon the secret code that only managers possessing the required credentials can know. I'm afraid you're going to have to be sacked...

    Seriously, I'd add that by definition, estimates cannot be accurate as they are just estimates. But they *should* be REASONABLE and if any accuracy is involved, it is with the actual work that will need to be done. But that is also inherently inaccurate because of the chaotic nature of humans.

    So the real trick to producing "great" estimates is (gasp) down to experience, knowledge, and skill. All the things that companies love to throw out the window and go for out-sourced replacements.

    Again, no wonder estimates are so unreliable in the mainstream corporate culture!
    70 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: