Why do we need estimates?

[NOTE: This post is about software development. You might need estimates in some other field or domain and this article is not related specifically to any other domain, and especially not the one you want to complain about.]

I’d like to do a little investigation about why we need estimates.

The following list contains some of the things people say when I ask “What do you use estimates* for in software development”:

  • To decide if we can do a project affordably enough to make a profit.
  • To decide what work we think we can do during “a Sprint”. (A decision about amount)
  • To decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
  • To decide which is more valuable to us: this story or that story.
  • To decide what project we should do: Project A or Project B.
  • To decide how many developers/people to hire and how fast to “ramp up”.
  • To decide how much money we’ll need to staff a team for a year.
  • To give a price, or an approximate cost so a customer can decide to hire us to do their project.
  • So we can determine the team’s velocity.
  • So marketing can do whatever it is they do that requires they know 6 months in advance exactly what will be in our product.
  • Someone told me to make an estimate, I don’t use them for anything.

That’s enough for a start. So let’s start.

Let’s notice the most obvious common word in that grouping. To me, it is the word “decide”. Granted, the last few items don’t use the word “decide”, but we have to start somewhere. Besides, why would have I contrived that list and highlighted the word “decide” if it wasn’t fundamental to my main point? [At least I’m honest in stating that I have an agenda.  Hint: NO ESTIMATES]

It is significant to me that much of why we do estimates is that we need to make decisions: To decide something.

In other words, it looks to me that what we need are decisions, not estimates. Estimates are often used to help us make decisions. Estimates are not the only way, and for many of the decisions we need to make they are likely not the best way, in my opinion. We can,  and maybe we should explore other ways to make those same decisions. [Who are we kidding, I really think we need to find better ways to make those decisions].

So to restate: We don’t need estimates, we need to make decisions.

Most of us will probably agree that decisions are important and we need to make them, and that we want to make “good” decisions. Great decisions are even better. Yet in many cases, mediocre decisions are sufficient [stay with me here…]

Interestingly, as long as we pay attention, learn from our mistakes, and are willing to make “course corrections” frequently, even bad decisions are often sufficient. In other words, even if we make bad decisions, we can adjust and steer our work (and therefore our results) by making decisions as we go along.  That is an important point. Dwell on it.

Perhaps it would be advantageous to find ways to work where the quality of our decisions are not as important as our ability to learn and to adjust our course while paying as little as possible for the learning, adjusting, and “mistakes”.

To me, this is a “Lean approach” to making software. To me, this is the “Agile way”. Some people used to call this a “light-weight methodology” for developing software to indicate the process was “barely sufficient” rather than “cripplingly  comprehensive and depressingly dysfunctional”. I like “light-weight”, but someone picked the name “Agile” for this idea. I like that word even better. Regardless of the name, it’s an approach where we pay attention to what is going on and constantly adjust things based on what we learn.

One other thing about decisions

Sometimes decisions happen by default: If I forgot to bring my lunch, my options are to go hungry or eat cafeteria food today. If I forgot to bring money, then the “decision” was made for me – I go hungry. I prefer to not go hungry, but in some cases a default decision is sufficient. Make decisions on important things, resort to default decisions on less important things. Besides, I need to lose some weight anyway.

One other other thing about decisions

One little note: Of the items in the “What do you use estimates for in software development” list above, there is only one where estimates seem to make sense to me: To decide how much money we’ll need to staff a team for a year.  I’ll write about that someday if anyone is interested.  But I am confident you can figure it out yourself.  Also, there are only a couple of items in that list that seem like important decisions to me. But what do I know?

One other other other thing

As far as the “team velocity” question goes – you don’t need an estimate for that. To determine the velocity of a team simply drop them from a height of about 2000 feet and you can measure their speed just before they hit the ground.  I’ve never tried that, but I’ve worked some places where it felt like that.

In Conclusion… We need to make decisions, we don’t need estimates.  Did I say that already?

So the title of this post was “Why do we need estimates?”. The answer is, we need them only if we can’t find a better way to make decisions.

There is a lot of stuff we need to decide, which requires that we make decisions. Make many small decisions while you learn, steer, adjust, and correct.

Some other posts I’ve written on the topic of estimating:

Perhaps you are now saying: So what? I don’t know of a better way, so I am going to use estimates. Besides, what’s so bad about estimates?  Well… I’ve written a little about that (although I’ve really just started – there is a LOT of potentially bad stuff about estimates we should all be aware of), and about a few alternatives to using estimates. Over time, I’ll keep adding more information, and share more about how to make decisions without estimates. In the mean-time, I know that many others are also finding ways to make great decisions without estimates, and some of them are writing about it as well.  Google that.  You can probably figure this stuff out better on your own, anyway.

NOTES:

* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.


5 Comments

  1. Ronald Voets:

    Inteesting point of view, even though i have to disagree with your main conclusion. I feel estimates are required on 2 levels. For the team, to forecast for themselves and their product owner how much they think they can do during the next sprint. Helps the product owner to decide which stakeholders (i.e. customers) to call for co-creation and feedback. On a more strategic level, it’s needed for the company to know they’ll deliver on the roadmap that’s externally communicated. Now we all know roadmaps can be flexible and scope isn’t carved in stone, but there’s softwrae industries that havr to comply with legislative chanegs (or prepare for such changes). In such an environment, the company (not just marketing as in your semi-last bullet), would need to get an acceptable level of understanding the Level of Effort and get comfort that they’ll comply with those changes on time. It’s not an estimate with a 2 dot precision level, but silent estimates on epics are certainly useful. if the outcome would be ‘now wya we’re going to get this done on time’ then additional investment decisions (and ramping up additional team(s) needs to be decided upon and acted upon as early as possible. if you do that 8 weeks before the deadline, you’ll only slow down the current teams.

  2. Glen B. Alleman:

    Woody,

    So if I have to decide to develop or buy a solution to my cost management system for a government program. Let me see if I can walk this through.

    (1) We own PeopleSoft and it’s procurement management system. That system is not well suited to customer (our customer) owned materials – We’re a Government Owned Contractor Operated facility. We could augment the processing, data, and UI for PS to deal with the subtleties of the GOCO environment.
    (2) We could develop a separate cost management system using tools we are familiar with – J2EE connected to PeopleSoft.

    How do I decide? We have an annualized budget for Operations, Development, and Maintenance of the product built here. There is a set-aside for just such things as we want to do. That budget is flowed down from the HQ of our customer every Oct 1st.

    I need to decide to built or modify. I have a due date of end of calendar year for use, since the people wanting the capability have a due date to report to the Govt HQ the information they need.

    How do I decide in the absence of an estimate for both options, showing that I have enough or not enough budget to do the work?

  3. Woody Z.:

    Hello Greg: You must invent the process you would use to make that decision without estimates. Almost everything about your hypothetical situation sounds wasteful and dysfunctional. If you have no influence on changing the process you are following, you must live with the waste and dysfunction if you wish to keep that job.

    Obviously, it is not estimates that are needed, but decisions. Simply because someone you report to requires that you provide estimates does not mean that it is a reasonable or useful approach to making decisions. It is merely the approach that is in place. However, if it is not your job to improve this process, you’ll have to put up with it.

    Cheers,
    Woody

  4. David Lowe:

    It’s rare that I read a blog post on Monday morning that makes me smile. Thanks (especially for the thought of dropping past dev teams from 2,000 ft)

  5. Woody Z.:

    Hey David – I’m glad you got a smile from my post. ALL of my writing is for myself, as a way for me to “think out loud” and it’s fun for me when others find it useful or meaningful in some ways. So… Thanks!

Leave a comment