In Learning

Don’t we just get frustrated when our agile estimates or guesstimates on timescales or costs turn out to be different from what actually happens? So how do we improve the accuracy of our estimates?

What do we need estimates for?

This is a golden question – ask yourself this whenever you do an estimate. It’s a lean principle to remove waste (i.e. non-value adding activity). If the estimate information you are producing isn’t vital for making a decision, then take a good hard look as to whether you need it. Some of the teams I have worked with have stopped some kinds of estimates as these estimates were not changing the decision.

Why are estimates uncertain?

Estimates are uncertain because we lack information. We’ve never built this particular feature before. We don’t exactly know what we need to do. As we work further with the feature, we gain more information and our uncertainty about how much work is required reduces. This leads to the idea of the cone of uncertainty shown below which suggests that uncertainty decreases (and hence accuracy of estimate increases) throughout the life of a feature.

Cone of Uncertainty

What helps improve estimating accuracy?

1. Break work down

If you only do one thing, break the work down into smaller pieces (this is a core lean-agile principle!) It’s much easier to estimate smaller activities than larger ones. By simply breaking down large work items into smaller pieces, your estimating accuracy will improve.

2. Increase the rate at which the estimator gains experience

Ability to estimate comes from learning from past experience of estimating. So get more experience! The way you increase your learning rate is to shorten the cycle time i.e. the time it takes to produce something. Halving the cycle time doubles the rate of learning!  Of course, the experience gained needs to be effectively captured (retrospectives, low staff turnover, etc.).

3. Ensure estimators are the people who are doing the work

Seems simple but in a lot of cases, the people doing the estimating are far from the actual work (or, sometimes, estimates are adjusted by people far from the work!)

4. Reduce dependencies

Typically if a task requires 90% of one person and 10% of another, the 10% person will be the bottleneck because his focus is not on the task. This means that it’s difficult for him/her to be available precisely when needed. Eliminating this dependency will reduce variation in timelines. Feature teams help with this.

5. Get multiple inputs

Agile teams often use planning poker to harness the brainpower of the entire team to improve the estimate – it’s unlikely that one person has all the best information. This is a fun and easy thing to try.

6. Agree on which estimate we want

Many timeline estimates are simply the earliest possible time for which the probability of delivery is not zero. Did you want the most likely date (50% chance of being early, 50% chance of being late) or the date for which it is almost certain delivery will have happened by? Make sure everybody agrees which estimate we are talking about.


7. Understand the politics

There are also all sorts of human dynamics that can skew your estimate. For example:

  • If there are “punishments” for getting it wrong, folk tend to add buffers to their estimates.
  • If folk believe that the uncertainty associated with the estimate will not be communicated clearly (for example to senior management) then they tend to add buffers. A solution to this that a lot of agile teams use when they are doing an early guesstimate is to use “T-shirt” sizing whereby the estimate is classified as Small, Medium, Large or Extra Large. Communicating guesstimates like this makes it clear that they are not very accurate.
  • If there is already a target declared (“we want this to be under $100k” or, “we want to complete this by June”) then folk tend to be anchored by that and don’t like to say it’s not possible. We all like to please our stakeholders.
  • Many fascinating studies show that people have a natural subconscious tendency to be overconfident in their estimating skills. If the estimator(s) have little data on past performance to help correct this, then its likely they will underestimate tasks.


Setting expectations on estimate accuracy

It’s tempting to set a team a goal to improve agile estimate accuracy. The risk with this (which I have seen in some teams) is that the quickest and simplest way of improving estimating accuracy is either to add undeclared buffers or to invest more time and resource before making the estimate. The latter effectively moves estimate creation to later in the lifecycle which destroys the purpose of the estimate (which is to make decisions early on in the lifecycle).

A better way of improving estimating accuracy is to set the team goals on reducing cycle time and reducing the size of items flowing thro’ the pipeline (as per the first two points above). By focusing on these general lean-agile practices, we also get an improvement in estimating accuracy!

Sign up to receive our newsletter and new posts

Recommended Posts
Showing 8 comments
  • The Agilista PM

    I couldn’t agree more…..I do this every project/program I can if the client allows it.   Many times I find that they want a “guess” upfront to approve the project or not – w/o doing what you outline.   My job is to convince them to take some time to get a more accurate estimate since guessing like they want can be anywhere from 2x-5x off.    The key is to do estimating with the actual people that do the work — since I’ve found that some can do things faster than others….and only they know how fast they can do something.  🙂

  • Nik Silver

    Excellent stuff.

  • Nik Silver

    Excellent stuff. And I would expand your first point, too: “What do we need estimates for?” It’s not just a case of “Do we need estimates?” but also “What difference will the estimate make?” Answering this question will help the team understand what level of accuracy and certainty is needed. If the answer is, say, “If it costs more than 100k then we risk losing our shirt” then the team simply has to make a judgement on that.

    There’s a lot more on this subject in Doug Hubbard’s excellent “How to measure anything”, which I recommend with embarrassing frequency.

  • Malcolm Sparks

    “By simply breaking down large work items into smaller pieces, your estimating accuracy will improve.”


    Reductionism is not a core lean/agile principle, or at least in none of the books I’ve read. This is one of those ‘self-evident’ statements which sounds-true-so-it-really-must-be but which has no actual basis in factual evidence. Much of lean/agile is counter-intuitive, and this is another example of a statement which sounds correct but is based on flawed reasoning.

    What evidence do you have that it improves estimating accuracy? How do you know that your breakdown itself is accurate? How do you know that your breakdown actually reflects the tasks you must do. Errors creep in at every level of reduction, to the extent that the aggregate error margin of the constituents could be greater than the error margin of estimating the whole.

    In practice I have never seen reductionism to be a successful strategy in accurate estimates, especially in software systems to which Agile is applied.

    The rest of the your article is excellent though. 

    • Paul Dolman-Darrall

      “By simply breaking down large work items into smaller pieces, your estimating accuracy will improve.”

      This one is slightly more than Reductionism. Smaller batches lead to smaller queues and queues have the largest impact on the duration of time something will take to complete. In this regard, smaller items will lead to more predictability, essentially improved estimating.

      However, large estimates can also benefit from variation pooling. Correcting errors made at a lower level.

      If we imagine 6 bus journeys of an expected 10 minutes, and 1 bus journey of expected 60 minutes.

      The 6 bus journeys may be as following -1, 2, -2, 1, 2, 3 minutes early or late. The estimates were approximately 18% out.

      But for the single journey, the estimate was only 8% out.

      10% improvement in the estimating is gained through variation pooling.

      This explains why I have always been more likely to be late, the closer I live to work.

      However, in the shorter example. I was never more than 3 minutes late, where as in the longer example I suffered from my cumulative optimism, and as such was 5 minutes late. My estimating was more accurate, but it can be perceived in absolute time as less accurate.

      So that leaves us with queue reduction. This will vary from team to team, organisation to organisation. This could really help, it explains why waterfall teams which were previously always late, appear to deliver on time (though scope shifting also helps). The impact of this could be strong enough to improve estimating accuracy.

      • Paul Dolman-Darrall

        It is also worth noting, regular delivery of value, tends to make estimates less important. Thus the reason, some companies stop doing them.

      • Malcolm Sparks

        It’s a false analogy. Software development is mostly research (since the manufacturing part of the process is largely automated these days). Therefore, to use your analogy, we’re not sure how many buses we’ll need to take, and any errors in our prediction of how many buses are not going to be excluded from the variation pooling effect.

        “By simply breaking down large work items into smaller pieces, your estimating accuracy will improve.”

        This is not the same as a small batch size, because you haven’t done any of those pieces yet. If you are being asked for an estimate for a large piece of work and you offer to measure the actual times for a slice of that work, that’s an ‘agile’ answer. But breaking up a task into smaller tasks, in thought only, does not equal small batch sizes. A design in one’s head does not equate to a finished product. The statement is still ‘big up-front design’ trying on agile clothes.

        That’s not to say that thinking and planning isn’t important, in fact, it’s crucial. ‘Plans are nothing, planning is everything’ as they say. But you can only use reductionism if you have knowledge of how the task can be broken down accurately – usually if you have this knowledge you’re manufacturing rather than developing software (which is research).

    • Graham Ashton

      I don’t think it’s tosh; in my experience the act of identifying what I’ll actually need to do to implement a piece of work leads to an excellent understanding. The more you know about what you need to do, the greater the chance that your estimates will be consistent.

Leave a Comment

How to reward your highest achievers?