Agile FAQs
  About   Slides   Home  

Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
RSS Feed
Recent Thoughts
Recent Comments

Estimation Considered Harmful

For years I thought I was a poor developer because I could not estimate well. Spending more time and effort on estimation did not really help either. (Predictability Paradox). One day it struck me that may be this whole practice is flawed and I’m not the only one who finds it difficult to estimate. Its been 6 years now and I’ve never looked back again.

Estimates are a hang-over from the waterfall world. For the last 6 years, I’ve been very happy and successful building products and delivering projects without all the estimation related ab-ra-ca-dab-ra. No more real-time, ideal-time, story point, function point; non-sense. I’ve realized the key is to focus on the flow of the deliverable and not whether your are delivering according to the estimates.

It turns out that most people don’t like estimation, but they do it because their Management needs it. Usually when Management asks for estimates, my question to them is how will this estimate really help? What if I said 6 months and I delivered in 12 months? What will really change? And if something really changes, will you do something about it now or you can handle that a little later? Again do you really need to know now or you can watch the rate at which we deliver useful features and plan those other activities later? And BTW how many times have your team delivered according to their estimates? If they did, did the thought ever cross your mind that the estimates were heavily buffered? (The bloat effect!)

I also commonly use the “throwing the dice” exercise to educate people about estimates. In this exercise, I ask the estimate obsessed person to estimate how long it will take them to throw 3 consecutive Six on a dice. Guess what, the person says how can I predict? Well there is probability theory and other great work that can be used, but ….

In most cases, it turns out that Estimation smells of lack of trust (because of past experience) and urge to push your risk on to someone else (so that you can point your finger to someone else). IMHO Management emphasizes on estimates for wrong reasons, rather than any true value those numbers provide.

Another thing to consider when we talk about estimates is, I can take 1 day to build a login screen or I can take 1 month to build it. The real question is how much sophistication your users need? In most cases you don’t know this until you see your users (at least proxy users) use the feature. So why estimate upfront and miss the opportunity to collaborate with your users?

When you start thinking about sophistication, then all of sudden you start thinking from a budgeting point of view rather than estimation. Most people get confused between the two things and interchangeably use one for another as if they were the same concept. What I see myself doing is regularly budgeting features by playing around with the sophistication knobs on each feature. This is yet another way to have your scope negotiable.

When we talk about estimation and it’s evils, I guess you must be aware of Student Syndrome.

So think about the real value of estimates and the effort spent on it. Is it really worth all the pain?

Does this mean we should embrace uncertainty? Yes and No. To some extent you can’t really predict the future so go with the flow. But on the other hand, you setup short (really short) feedback points to correct your direction and hence keep the chaos under check.

  • Pingback: amit klein » Who Needs Estimates?()

  • Ash Tengshe

    Naresh. Hello old friend. I dug this one up. As many of you who posted, I’ve been on both sides. I now manage a large software development group at a massive healthcare firm. Here is the problem in my view:
    1. Estimation (of Date or Cost) is hard. It is harder when the variables increase. It is hardest when you have no control over few of the dependencies.
    2. I disagree that business or mankind in history always had estimates. If so, pray tell me when we will find the cancer vaccine/cure? There are businesses trying this as their #1 product but they have no estimate to give out. Take History, it took 16-21 years to build the Taj Mahal. Did the emperor have this estimated?
    3. Why #2 above is acceptable is because is because we all agree that the task at hand (Cancer/Taj) is extraordinarily difficult and never done before.
    4. So, software should also come in these categories: Are you building automated cars that maneuver themselves in rush hour LA traffic? Or are you storing and retrieving data for my accounts? IT industry would do itself a huge favor by standardizing the relative complexity of the projects on a 1-10 scale. These would be the project “story points”. I know it is difficult to standardize projects into these classifications but that would be a worthy attempt.
    5. Then it would be even better to say if we are doing a Level 1 Project, our estimates are going to be +-20%. If level 7 Project (a complex algorithm for artificial intelligence) then the estimate would be +-100% or more.
    6. The last point I want to make is: IT needs to learn Business very very well in order to offer options that fit within the date/cost. This is by far the main problem as I see. IT becomes order takers and then complain. Become partners and say OK if you have to have it by December, here is what we give you and see, you still are able to do business! 🙂 I can’t see how we get there fast enough. Every author says “Business dictates dates/IT dictates features” but that doesn’t happen. Usually Business dictates both 🙁 Unless IT thinks “I am business” and learns it inside out, there is no solution.

    Ash Tengshe

    Licensed under
Creative Commons License