Estimates Are Not Commitments But…

Unfortunately, they very often are.  Recently, during an interview, I asked the candidate what they thought about the notion that “estimates are not commitments“.  The candidates answer was:

Once an estimate is put down on paper, it unfortunately becomes a commitment.

Performing a search for estimates are not commitments returns a good number of results so this is not really a new subject.  Yet, to be fair, it’s important to realize that many of the articles are authored by individuals in the Agile software development delivery space so do we have an agenda?

In previous articles, I’ve tried to define what an estimate is, so I won’t repeat that here but suffice it to say, that an estimate is an approximation of a measure.  On the other hand, a commitment is defined as the following:

  • an act of committing to a charge or trust
  • an agreement or pledge to do something in the future

So its very clear that estimate and commitment are not one and the same thing.  How is it then, that estimates are very often interpreted and/or immediately translated to commitments?  I’m not sure I have a good answer for that yet, but I’d love to your feedback!

What I do think is important is understanding what the the requestor of an estimate is looking for.  An estimate?  A commitment?   The response for each could be remarkably different.  So when you are being asked for an estimate (and let’s just assume for a second that one is truly needed), make sure you understand what you are really  being asked for.

Estimates are not commitments.


11 Replies to “Estimates Are Not Commitments But…”

  1. I think estimates become commitments because clients/customers don’t really want estimates – they want to *know* – thus they want commitments.
    And I think it’s fair.
    When a buy a TV or want to remodel my kitchen or anything I most often don’t want to know what I “roughly” can expect to pay, I want to know what I *will* pay.

    We, as estimators, somehow fail to realize this. We should probably never communicate the estimates, we should communicate commitments.
    And in this realization (or failure to realize) lies the problem I think.
    I think we’re afraid of “loosing the deal” or that someone will get “upset of the high price” or “it can’t possibly be that hard!” or that we’ll get any other reaction but a positive one – if we started to communicate what we think we can *commit* to instead. An estimate will get a more positive reaction (hopefully).

    But we’re fooling ourselves and our clients. So, just stop it 😉

    Commitments are also close (or the same?) as promises. And promises are powerful things. Be careful. Read some here:

    So I wonder what good commitments of outcome really brings?



  2. > How is it then, that estimates are very often interpreted and/or immediately translated to commitments?

    Simple. For example: PM asks developer for an estimate to fill some piece of paper. Dev gives an estimate with some number of hedges or confidence level. Too bad there was only a place for a numerical estimate in the paper. The paper now floats around the organization & anyone reading it only sees the number and interprets that as fact, since that’s what it looks like. Oops!

    Add silos, infected relationships between dev / PM / biz, perhaps some messed up incentives and the situation becomes so much worse.

    How to remedy? Communicate, communicate, communicate. And hopefully share a world-view where projects and knowledge work are probabilistic in nature, not deterministic.


      1. Yes.
        This might seem a little bit silly, but I actually see education as a form of communication 🙂
        As in; communicating “common knowledge” or “what I’ve learned/experienced/know” and similar.


    1. Hi @Ari – Thanks for the comment. I am still curious as to what drives the behavior you consider simple. Why would a PM (who really should know better), turn an estimate into an commitment? Good to point out that commitments themselves are also not deterministic, as much as we act as if they are. Which is why we must be careful “what” we commit too and “how” we commit.


  3. Yes and this is the reason the scrum guide replaced the word commit with the word forecast. I think making some commitments to your customers is important sometimes but you should only commit to a specific date if you are very close to certain that you can complete the work to a satisfactory quality by that time.


    1. Yes, that change is important. In my post, “A Town Called Commitments”, I talk about commitments but intentionally left this point out (for another upcoming post).

      Thanks for the feedback.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s