Uncategorized Toggle

Estimation or Die – is feature estimation a good idea?

<h1>Feature Estimation</h1>

I have read an article recently that took the view that development teams doing feature estimation could be a harmful thing. It was well-written, and well thought-out, and the cut of the jibe goes something like this:

  • Estimation can be wrong, often to a 4x level.
  • Estimation can be time-consuming and that time could be better spent
  • Estimation, if incorrect, can have a negative impact on the engineers that provide them

I think there are some good points here. I know from playing agile poker on half-day sessions that you can get lost in estimation. Whether the question is around “what does a 1 mean, complexity or time taken” to the examination of an edge case of an edge case of an edge case, then there are times when the process is expensive, can feel like a not-great-use-of time, and still not eliminate the risks that we want to avoid.

For what it’s worth, I think it has a real place in any decision-making. If you imagine that every store in your city decided that all goods were free for 24 hours, you could just walk in there and take whatever you wanted as long as you could carry it, then think about how many things people would take home. Ask yourself how much of that stuff they really value? There is an implied benefit here of knowing the cost.

I have seen people who really want a feature suddenly say it’s not that important when I tell them how much engineering time is involved. I have also seen people suddenly turn to me and say “that’s expensive, all I really need is this small part of it”. I have even seen people who were swearing to me how important this was, suddenly remark “this is a nice to have”.

<h2>My Approach</h2>

There are a few things I normally do to find out “what people are willing to pay”

  1. Get people to list everything they want, so that all that stuff “is on the list”. This is critically important.
  2. Get the person to order things say from 1 to 5 where 5 is the most important.
  3. Get them to explain why. The why is actually the most important thing – often people’s suggested solutions aren’t the best way to fix the pain.
  4. Take all the 1s and get them to list them in terms of most important first. Tell them to assume any one thing could be delivered tomorrow when doing this exercise.
  5. Now come back with a rough engineering estimate on this list. Spend an hour with the team putting rough estimates on them, any more is a waste of time
  6. Present the cost back to the person, saying ‘if we only worked on your stuff’, the whole lot would take X weeks. do you need it all”

I find that this gives the person some reassurance (you captured all their requests in step 1). It also lets them explain their reasoning (pain) why things are important. It lets them quantify and order their problems and opportunities. And it gives them a way to sense check that the cost of a solution is proportionate to their pain/opportunity.

<h2>Estimate or Die. Really? Die?</h2>

For this reason, I think estimation is an essential part of prioritization. I think the caveats around estimates being wrong are somewhat valid, but for relative sizing it still works very well, and most teams get better at estimating over time. Bundle estimating with planning and you’re on to an even better use of time. I think the alternative to estimation may not be “die” but is certainly a sub-optimal use of resources. Doing this over a continued use of time could well mean the end..

About the author

Patrick Patrick O’Malley is an Internet and web professional passionate about building products that people love.

Now a product based consultant, he is ex-Head of Product, Yahoo! Answers, ex-Head of Operations MoveMe and an Imperial MBA.

Based in Paris (a bit) and London (a bit).

You can follow him on and Twitter or check his bio

Leave a Reply