Stop Using Single Point Estimates

sign showing lightning striking a man and declaring danger of death

Single point estimates are not suitable for use by children or pregnant women and in extreme cases may cause death.

Estimating how long it will take to develop software is difficult. Fortunately, as an industry we’ve moved away from big-planning-up-front, exhaustive Gantt charts and toward a more agile approach. Unfortunately, we’ve stuck with single point estimates which have some significant disadvantages when compared to range estimates.

There are a variety of ways you can use and interpret range estimates. Here’s the method I use which has worked well for me:

  • Step One: Start with a list of the requested work to be done for that iteration.
  • Step Two: Break these down into a list of small tasks.
  • Step Three: For each task, give a happy estimate. This is how long you expect it to take if things go well.
  • Step Four: For each task, give a sad estimate. This is how long you expect it to take if you encounter problems along the way.
  • Step Five: Sum up all of the happy estimates. It’s pretty much impossible for the iteration to be finished in less time than this amount.
  • Step Six: Sum up all of the sad estimates. This is a realistic upper bound. It’s very unlikely that the iteration will take longer than this amount.
  • Step Seven: For each task, average the sad estimate with the happy estimate. Sum up these averages. This will be a relatively accurate estimate of the time it will take to complete this iteration.

Step two involves breaking down the business requirements into the corresponding technical tasks. Often there is a one-to-one correspondance, but sometimes not. Any task that feels like it could take half a day or longer is a candidate for breaking down into subtasks. Breaking large tasks into smaller tasks is one of the keys to better time estimates.


Breaking complex tasks down into smaller steps is one of the keys to better time estimates.

How you think about sad estimates and happy estimates is important. The sad estimate is not a worst-case scenario. Worst case scenarios are unlikely, and you’ll just end up with an exaggerated time estimate that hides information. I think of a sad estimate as a likely bad case scenario and a happy estimate as a likely good case scenario. What I aim for is that 10% of the time, the task should be completed faster than my happy estimate and 10% of the time it should take longer than my sad estimate.

Note that the time estimates are hours of development time, not dates. They should not include the time for meetings or other non-development tasks.

Why Range Estimates Are Better

Single Point Estimates Hide Useful Information

There is only one piece of information in a single point estimate. There are three pieces of information in a range estimate. In addition to the happy and sad estimates, the length of the range is valuable information. It tells how much risk or uncertainty is in the time estimate. Why throw away this useful information?

Range Estimates Remove Bias

statue of a woman holding scales

Range estimates help keep mood and politics from influencing time estimates.

Sometimes programmers are overly optimistic in their estimates. Perhaps they are really excited about the task and their low time estimate reflects a positive, can-do attitude. Or maybe they are afraid that if their time estimate is too long, their pet feature will get canned.

Sometimes programmers are overly pessimistic in their estimates. Realizing that unexpected things can go wrong, they add in arbitrary buffers, like multiplying their initial estimate by two. Or if they are in a culture where time estimates are mistaken for commitments, they have a lot of incentive to inflate the estimate to avoid “failing” by missing it.

Single point estimates are subject to these biases. Furthermore, when looking at a single point estimate, you can’t tell whether it’s an optimistic or pessimistic estimate. Range estimates force both yellow hat and black hat thinking for every task, so the bias gets thrown out from the get-go.


I’ve used this successfully working one-on-one with a business founder, but I’ve yet to see range estimates used in teams. I’m eager to see this happen, but not hopeful, since many tools like PivotalTracker and Trajectory assume single point estimates.

Additional Resources

I’ve made an example Google spreadsheet that sums and averages your range estimates automatically. Feel free to copy this spreadsheet and use it.

This article on range estimates is also useful reading.

You can skip to the end and leave a response. Pinging is currently not allowed.

11 Responses to “Stop Using Single Point Estimates”

  1. Ferrous says:

    I’m a big fan of estimate ranges. I’ll add one additional reason: you can use uncertainty or high max values on an estimate to apply pressure on the requirements. Sometimes the business users claim they want more than they really do for a feature’s details, or sometimes frank conversations need to be had to exclude some possibilities or requirements.

  2. I agree that it’s healthy to do range estimates internally, but I don’t believe it’d be good to expose anything but the sad estimate to your clients. How would you feel if you ordered an iPad and they told you it’d be between $199 and $499. You’d always be hoping for the lower price, as will your customers.

    If you want to under promise and over deliver, exposing only your high estimates is a step in the right direction. You always get to over deliver. =)

    Just my two bits.

  3. techiferous says:

    Hi Gregg,

    Thanks for your thoughts. In my (limited) experience with range estimates, I’ve found that it was very helpful to the client in that it gave them a sense of control and predictability. I don’t think the iPad is a good analogy because iPad is one-size-fits-all, whereas web application development is bespoke and subject to heavy negotiation about the scope and timeline.

    What I’ve found is that the range estimates gave valuable information to the client that allowed them to make strategic decisions. For example, if I give a range estimate of 1-8 hours, I’m saying that it might be quick but don’t be surprised if it takes 8 hours. The client may decide that 8 hours is too much effort for that feature and cancel or delay that feature.

    Another example is if I estimate a feature to take between 2-16 hours. The client can ask why such a large sad estimate and I can respond with the difficulty of supporting IE6. The client may then decide that IE6 support is not worth it and to re-estimate for IE7+, and I can come back with 2-4 hours.

    So I find that the range estimates give more information, and therefore power, to the client to make strategic decisions.

    But I do think you make a very good point in that managing expectations is important. Underpromising and overdelivering is not a bad strategy, and depending on the collaboration style you have with a particular client, I can see where you may not want to expose the range estimates.

  4. I’m a fan of point-based estimation at the story level. A point value already represents a range — “5-8 points” doesn’t make sense when your point values are (1,2,3,5,8,13). A range of time units might make sense at a finer-grained task level, but in my opinion the story point abstraction is a more useful tool for computing velocity and planning.

    The Planning Poker process eliminates bias, and engages product owners in the estimating process.

    If you haven’t already, I recommend checking out “Agile Estimating and Planning” by Mike Cohn.

  5. dude says:

    Wow, personally, how about 0-point estimates. Just do the work, it’ll take some amount of time, eventually it’ll get done.

    I fail to see the value in spending time thinking up time estimates and filling out fields in a project management app. Then again, I also fail to see the value in spending time in meetings, so perhaps this article just isn’t aimed at developers like me/teams like ours.

    It’s one thing to be like “a couple days” or “this afternoon”, and another to pull some magic numbers out of thin air.

  6. @dude I agree, at least until you’re on a team and need to plan further out than a day or two.

  7. @Jeremy I agree with you. We use the Fibonacci sequence for story point estimates and doing it this way is the same as using a range. I think this concept is often lost or forgotten and people just look at the number given. It’s important to remember (and to educate founders or clients) that when looking at estimates developers have given, saying 5 really means ‘I think it’ll take longer than a 3 but less than an 8 and will fall anywhere in between’.

  8. Excellent post.
    Since I found it very inspiring, a wrote a (long) comment on here

    “8 rules to be successful even when forced to use Waterfall (with a pretty good estimation)”

    I hope you won’t mind if your name is the most cited one 😉
    The fact is I strongly believe you are very right about ranges estimates, and in the same time I feel the need to explain where my point of view was different than yours.

    Thanks for your very good post

  9. techiferous says:

    @Arialdo: Thanks for furthering the discussion! You’ve brought up some great points, especially around the team dynamics of software estimation. I’ve yet to try out range estimates in a team setting.

  10. We have settled on an up front design phase, even if the client already has done some up front design. This phase is best described as a step beyond wire-framing, but no polish. When we feel the design is in a good spot we can then make an informed estimation on the development time.

  11. Chris Edwards says:

    Only just stumbled upon this thread sorry, but what I do is use a percentage certainty calculation for the “sad” end of the scale. You decide your “happy” time, then say in terms of percentage how sure you are you will get it done in that time; the result is rounded up giving you your “sad” / upper end of the scale.

Leave a Reply