Why Do We Estimate, Anyway?

I've been thinking about estimation these days. After the healthcare.gov site fiasco, and all the schedule games–many of which are estimation problems, I thought about why we estimate.

The larger the effort, the more we need to estimate. And, the more your estimate will be wrong. The more we estimate, the more we have schedule games. The smaller your effort, the easier it is to estimate.

That's why I suggested you use agile approaches in this estimation series. You can break things down, and iterate. You get more information, and estimate smaller chunks. You are more likely to have accurate estimates.

Software is Not Construction; Software is Learning

Here's one problem I have with estimation. Software is not construction. We can't build software the same way we construct or manufacture anything. Software is all about learning as a team. We can timebox our learning. We can choose to stop doing something. We can put acceptance or release criteria around it and say, “We have done enough for now.”

But, we cannot say, “We can build this software for $xx per square foot.” We don't know how to do that. Because we have not built exactly this software before. If we had built software like this before, we can estimate pretty darn close, because we either have historical data with good estimation quality, or we have small chunks of work we know about, or both.

When we estimate, other people think of our estimates the way they think of estimates in other fields, especially construction. Especially if you provide a single-point estimate. Even if you provide assumptions, which no one hears.

We estimate for these reasons:

  1. To provide an order-of-magnitude size/cost/date about the project, so we have a rough idea of the size/cost/date for planning purposes. An order-of-magnitude size means we want to invest just enough time in the estimate that we believe in the accuracy of it for planning purposes.
  2. We want to know when we will be done, because we are close.
  3. We need to allocate money or teams of people for some amount of time.
  4. Someone wants to know who to blame.

There is an alternative to estimating

Remember I said software is about learning? And, remember I said we never (okay, almost never) do the same software project twice?

Here's something you can do. Make your features really small. Swarm (or as Woody Zuill says, mob) over every story every day. Always finish one or more stories every day.

If you always have deliverable software—this includes all tests, documentation, everything you need—you don't need to estimate anything. You also gain the benefit of learning, so if someone asks, “How hard is thing to do?” the entire team can huddle together for a few minutes and say, “It's this story and that story and this story, too.”

They then say, “We know it's at least these three stories, and that's off the top of our heads. Are those stories more important the ones at the top of our queue?”

What Do You Do? (Or, Prove It, JR!)

I don't estimate my work. I work in chunks of work that take anywhere from 5 minutes to one hour. I rarely work in one-hour chunks. Most of my work takes less time than that.  I doubled my output this year by moving to smaller chunks of work.

I finished one book this year, and have another in beta. I have more books in progress. All while maintaining the same number of speaking and training engagements. I wrote roughly the same number of blog posts. I edited more agileconnection.com articles. Why can I do more?

Because my tasks are small. Because they are small I don't have to estimate. I don't have estimation time built into my work. I work in flow. That changes everything. I rank what's most valuable at any time, and work on that.

Why Do You Estimate?

Why do you estimate? If you've estimated because you always have, think about it. If you estimate because your money people want to do once-a-year money allocation, well, you know that's fiction. You can do it without detailed project estimation.

For money allocation, decide how valuable the project is to you. When does the project have to deliver the value? Now, tell the project team when the value has to be delivered. That's all.

Remember, you hired these people because they were smart, responsible human beings. Stop with the phases and all that nonsense. Tell them what you want. Remember, the phases exist because management wanted to be able to cancel the project before it got too far along. You were supposed to show a deliverable and re-estimate at each phase. If don't cancel, deliver, and re-estimate at each phase, your phases are not working for you.

Buy them a copy of Manage It! Your Guide to Modern, Pragmatic Project Management, which explains how to manage projects in any lifecycle. Give them a ranked backlog. Let them deliver. If they can't deliver in the money or date frame, they will tell you. They are responsible humans.

If you need an order-of-magnitude estimation, fine. That doesn't take days to determine. That takes hours. It will be precise-wrong and order-of-magnitude-right. Timebox it. It's an order of magnitude. Don't hold anyone to that estimate. (Quick, what's the definition of estimate? “Guess.” That's the definition. I kid you not.)

If you want to know when you'll be done because you think you're close to the end of the project, ask yourself this question: Is it worth the time to estimate vs. the time to finish? It might be. But know you are taking time away from finishing.

And, if you want to play the blame game remember that management is the one who needs to shoulder the most blame. Why? Because management set the constraints. Don't believe me? Read the estimation series now.

I can sympathize with management's need for estimates. I like order-of-magnitude estimates for many things. I even like specific estimates as we get closer. But creating software is not like driving someplace or like constructing a building. When I drive somewhere, I do want step-by-step instructions. When constructing a building, I do want an estimate. And even then, I am pretty sure the estimate is optimistic.

When creating software, I want to see working software as we create it, because with software, we learn. The learning is what's most important. Because once we've learned enough, we can stop. That's what's most valuable. Not the estimate.

12 thoughts on “Why Do We Estimate, Anyway?”

  1. Solid thoughts, JR… but there is still a reasonable need for estimates to support management decision making. We do need to set realistic expectations about the uncertainty of estimates… and all of your warnings and alternatives are sound. At the end of the day, the people paying for a system should be able to do a crude ROI and they need to know the investment required.

    A really dense Risk Management book I was reading last week had an interesting biblical quote: Luke 14:28 “Suppose one of you wants to build a tower. Won’t you first sit down and estimate the cost to see if you have enough money to complete it?”

    Seems we are not the first generation to want estimates. ; )

    1. Payson, you are correct. That’s why we need order-of-magnitude estimates. We might even update these estimates as we proceed, to make sure the project doesn’t last longer than the value will. Sometimes you don’t know at the beginning. But you certainly know as you proceed!

  2. It seems so obvious once you see it, but the ‘learning’ aspect of sw dev as a way of describing how it is different has eluded me when trying to speak to the same thing, why sw dev is not like constructing a house. I don’t think I have seen any other writer describe it this way either, so kudos!

  3. Pingback: Five Blogs – 29 October 2013 | 5blogs

  4. Hi Johanna,

    I just wanted to say great post, I really enjoyed reading it. It also nicely encapsulates what I’ve learned operating in both sides of the project relationship (engineering and management).


  5. Pingback: Why Do We Estimate, Anyway | Development Block

  6. Sam Pakenham-Walsh

    Johanna’s question – Why Do We Estimate, Anyway? – opens a can of worms, causing all kinds of issues to crawl out: from the benign we-just-wanted-to-know to the malignant but-you-told-us. Any way you look at it, the only people who ask us to estimate are those who want (who are weighing?) a mutually beneficial future relationship: this is a GOOD THING, as 1066 & All That would say.

    I would submit that there’s a valid argument to respond in a relational – not in an operational – context. This may well mean answering the question with a question, the goal being to build a relationship, not to negotiate a contract – to learn, not to “succeed” or “fail”.

    I believe that a more fruitful WHERE-are-we-going & WHAT-are-we-trying-to-achieve will come from responding relationally, not operationally, but I have no roadmap at the HOW level. Any ideas?

    One of my clients may give us pointers to a roadmap. With this one client I negotiated a fixed monthly retainer based on my per diem rate. This way, the client would have an exact estimate!
    RESULT: Each month I got my retainer & sent the client a “bill” stated in time-units, not in dollars. Of course, my “bills” were less or more than what my per diems would have amounted to. In effect, any inexactitude in our joint estimating was my headache – not the client’s.
    CONSEQUENCE: An excellent relationship was established that lasted for years – & from which I worked with a good many contact-clients whom I’m sure I never would have met otherwise.

    I suspect that the key phrase in the above paragraph is “joint estimating”.

    – Sam Pakenham-Walsh
    P.S. Good question, Johanna!

  7. Good post – though I agree a crude ROI is needed for decision making. A pressure point to consider also in B2B companies is clients who want to know by what date some functionality will be available. No easy answers on that one.

    @David – I’ve used a different analogy to address the same thing recently. Some companies are guilty of thinking of “Development” but forgetting that there’s an “R” (RESEARCH) with that “D.” (R&D) That’s resonated for me, so feel free to use it if it helps!

    1. John, Instead of ROI, I wonder if they could consider an order-of-magnitude estimate and a value?

      If ROI is a prediction that is un-knowable. See Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio.

      It’s a question. I’m sure it’s not the way “they do things around here.: 🙂

      If they want to know a date some functionality will be available, that’s relatively easy, if you’re agile. The product owner creates a roadmap, and ranks the features in the backlog. The management okays the product owner’s ranking. It’s up to the management to duke it out with the product owner. It’s also up to management to keep every single member of the project/program on one, and only one, project/program at a time. That way people can have the most throughput as a team, which is what counts.

      You work on each feature in the ranked backlog, preferably swarming as a team. That moves each feature to done. You see where you are in the roadmap. You see if you’re going to make it. (This is part of the estimation series I referenced.) You can tell pretty soon, in the first few iterations, what your predictable velocity is. If you have a good Product Owner, one who writes relatively the same size stories, bam, you can predict. I would still use confidence ranges.

      But, can your company predict the market? How far out do they want to predict? All this prediction is a little nutso.

      Management is overthinking things. They should commit to a little something, have the teams do a little bit. Get a little feedback, replan. Project Portfolio Management. It is difficult to make decisions. If the teams provide demos of working product, it’s not so hard.

  8. Sam Pakenham-Walsh

    Johanna’s “iterations” apply to ALL operations – not just to I.T. projects. Let’s call it by its proper name: Plan-Do-Check-Act. Or, as I prefer: Plan-Do-STUDY-Act. One of my colleagues asked Ishikawa how Americans differ from Japanese. He replied: “You Americans are linear, not cyclical, thinkers. You ‘Plan-Do-PutOutFires’.”
    “Go, Tell It On The Mountain,
    Over the hills and everywhere!”

  9. Pingback: New PM Articles for the Week of October 28 – November 3 | The Practicing IT Project ManagerThe Practicing IT Project Manager

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: