3 December 2011

Why you guys suck at estimating

Planning poker

Kailash wrote a great blog post on estimating. It gives the maths behind why you guys suck at estimating.

Go read the post here.

Kailash tells us that essentially your success at estimating is amplified by doing it Delphi (blind group) style.  This includes Mike Cohn's planning poker approach to estimating.

That means that your estimates increase your capability if you get many people involved.  Unfortunately, if your team's average estimating capability is poor you'll be amplifying poor estimates (ie moving further away from the eventual truth.)

His post comes with disclaimers and it would be neat to test this out with some experiments, but it is one of those ideas that 'feels' right.

This post is my response to the ideas he presents and some additional thoughts on the problem of estimating.

It's timely for me right now because I have been doing some estimating work for my team's 2012 portfolio and I have been pretty much ignoring all recommended best practices for estimating and instead guessing most initiative sizes using my instinct.

What makes me think I should be doing this rather than using a consultative, and in particular a Delphi approach to estimating projects?

Why am I more reliable than many other people who have worked here longer?

First and foremost I believe that most in our team are not particularly competent at estimating.  So I trust my judgement more than theirs.  I've been around and educated myself about estimating. I have also been around and gotten a feel for how much effort things both 'should' and 'do' take in organisations of various maturity.  I have a breadth of experience.

Additionally, in my current estimating work I looked back at historical performance and looked at sizing next year's projects against last years.  This gives me a feel for the capability of the organisation.  Relative sizing works for me.

Additionally I don't actually do it alone.  I have asked others to estimate in some instances.  But again I have gone to individuals rather than the whole team that is to do the work.  (Some teams aren't even hired yet.)

So Kailash's post gives me confidence hat I am not doing something stupid and there is some theory that stands behind my instinct to keep the estimating activity to a small group of people.

There is a better way.

You may suspect that  better way could be developed by giving everyone experience participating in estimates so they can build their competence.  We could do that, and should for a handful of people for the occasions we do need to estimate things.

The better option is to gather historical data and use that to forecast the future.

In the course of next year I'll be working the team to gather data so we can get better historical numbers.  In the next annual planning cycle I hope we'll be 'counting cards.'


  1. Interesting article. I also find very hard to make estimatives a processual and scientific task. As you noted, it has a lot of expectation attached to it and experience is the key to balance things to get the optimal number... I believe it gets in the engeneering paradigm of "possible" instead of "optimal".

    1. Thanks Bruno. Expectations are important and we do work hard at managing them.

      I like the "success = experience/expectation" idea. It illustrates just how important expectations are.

  2. One suggestion: look at this book "How to measure anything" D. W. Hubbard (http://amzn.com/0470110120) for interesting insights on estimation.

  3. Carlo, I enjoyed the ideas in that book very much and do intuitively apply them when data is in shirt supply.