A fundamental and common problem in many organizations is that estimates and commitments are considered equivalent. A development team (agile or not) estimates that delivering a desired set of capabilities will take seven months with the available resources. Team members provide this estimate to their manager who passes the estimate along to a vice president who informs the client. And in some cases the estimate is cut along the way to provide the team with a “stretch goal.”
The problem here is not that the team’s estimate of seven months is right or wrong. The problem is that the estimate was turned into a commitment. “We estimate this will take seven months” was translated into “We commit to finishing in seven months.” Estimating and committing are both important, but they should be viewed as separate activities.
I need to pick up my daughter from swim practice tonight. I asked her what time she’d be done (which we defined as finished swimming, showered, and ready to go home). She said, “I should be ready by 5:15.” That was her estimate. If I had asked for a firm commitment—be outside the facility by the stated time or I’ll drive away without you—she might have committed to 5:25 to allow herself time to recover from any problems, such as a slightly longer practice, the coach’s watch being off by five minutes, a line at the showers, and so on. To determine a time she could commit to, my daughter would still have formed an estimate. But rather than telling me her estimate directly, she would have converted into it a deadline she could commit to.
Don’t let your estimates become commitments. Remember the difference between an estimate and a commitment and keep the two activities separate, educating management and customers as necessary. I talk much more about agile estimating and committing in my new book, Succeeding with Agile.
Tags: agile estimation
I could not agree with you more. There is this tendency to treat estimates as full blown commitments. Since when did the word estimate in the dictionary equal commitment? I am looking forward to reading Succeeding with Agile.
Hi Eric–
I think there’s some human nature tendencies that must cause this. It’s too universal across all cultures to equate the two.
Very good points, and when running reports I always try to use the proper language to differentiate between what the original estimate was and what the commitment to the client is. Need to keep drilling this in to upper management until it sinks in!
Good point, Dina. We should take every opportunity to communicate both the estimate and the commitment together.
I definitely agree with you that estimation is often treated as commitment by the business, which can be frustrating. The way i see it, is all about the scale of the estimation. If you’re estimating the whole project that can take upwards of 6 months, then it should be understood that the numbers are basically pie-in-the-sky.
But when you estimate on a much smaller scale e.g. an iteration, much smaller project, the surely your estimation should approach commitment? Infact, I believe that a good goal for a team to strive towards (as they work together more and more and the project progresses), would be to be able to confidently commit to their estimated targets (without drastically underestimating).
I completely agree with your point of view. This is actually one of reasons why I teach all my teams to use Story Points, because in this case estimates use units separate from time measurement and it can’t be used as commitment
For product and project management we plan projects in number of sprints, which gives us some backup and freedom in commitments.
Hi Alan–
I think there’s always a difference between an estimate and a commitment. You do the estimate to figure out what the right commitment should be. I think the way to think about this in regard to longer or shorter projects is that the uncertainty (range) of the estimate should be smaller with shorter projects. For something big and vague I might say “I estimate 12-18 months” but for something smaller I might estimate “We’ll be done in 4-5 sprints[8-10 weeks].”
Turning each into a commitment will always be a somewhat political process. I remember all the heat Microsoft was taking over Vista being late. I can imagine early thinking that said “3-4 years so let’s announce 3-1/2 years.” But then as they were late a few times, I would have taken an attitude of “Man, we get crucified every time we’re wrong. Let’s make sure we’re not wrong. The press is too harsh. The math says 6-9 more months. Let’s commit to 10 months.”
So, we do an estimate to figure out what to commit to. Company culture, competitive pressures, etc all factor into the conversion from estimate to commitment.
Hi Tim–
Great point. I used to make that point in my classes as an advantage to story points. I think I’d forgotten it because I don’t think I’ve mentioned it the last couple of times. Thanks for the reminder of another benefit to story points.
This is true, but what can you do when the managers don’t understand this distinction, when they think the estimation has to be “realistic” (it means a commitment)? I saw cases when the managers think that if the estimation is not a commitment, then the developers have an “open door” to do not accomplish with the tasks created in the project in the time estimated.
What do you think about this Mike?
Hi Deusdit–
Before determining the commitment we need to think about the audience. If you decide “4-6 sprints” is your estimate and need to convey that to someone who will hear “4″ when told “4-6″ then think about whether you really want to say “4-6.” The loser in this situation is the recipient of the commitment who, by that unreasonable behavior, loses the opportunity to learn the full estimate.
I haven’t said we should always communicate the estimate.
[...] [1] http://blog.mountaingoatsoftware.com/separate-estimating-from-committing [...]
Hi,
actually I wanted to disturb the peacefulness here a bit, but then my example “broke down” while writing
Let say you car is broken and you go to a mechanic and he tells you it will be finished tomorrow and it will cost you 200$. Three days later you get your car back and you’ll have to pay 800$ and the mechanic tells you: “oh sorry, that was just an estimation”.
I actually wanted to point out, that this is a very unpleasant situation, but then I realised that it is also a very common one too. But still unpleasant.
While I fully support the differentiation between estimation and commitment, we still have to find ways for both “parties” to be happy with. For me this allways leads to small, but committed(!) deliveries in order to build trust and that you constantly have to monitor and discuss deviations from the original estimation with your client.
At the time of the estimation not only the costs are estimated but also the result. In a trustful relationship there is always a lot of you can talk about.
The goal is to make the estimation become real – “estimation is not commitment” should not be an excuse for “neverending” projects or high costs, but a call to work together to meet the expectations of both parties at the end.
Heiko
Hi Heiko–
Of course I would be frustrated if my mechanic initially told me $200 and later charged me $800. But let’s look at a couple of key assumptions. A key premise for me is that estimates need to *always* be accurate, meaning the mechanic gave an inaccurate estimate. If giving an estimate, he should have said “from $200 to $900″ or such. It would then be my fault if I were frustrated at the $900. (Or I could have asked him to reduce the uncertainty [reduce the range] but that might have cost me $75 for him to take the car apart to know exactly how he’d fix it.) This fits with your suggestion of incremental deliveries. However, there is still the possibility that incremental delivery ends up expensive. If I pay the mechanic $75 to take my car apart and he decides it will cost $900 total, I may decide to forgo the work in which case I’m out $75 of investigation cost.
[...] Separate Estimating from Committing | Mike Cohn’s Blog – Succeeding With Agile®. [...]
[...] Separate Estimating from Committing [...]