Estimation Has a Cost by Ron Lichty

Mike Cohn asserted, in a blog post a couple years ago, that estimation is not by definition waste. When, to his astonishment, he ended up in a Twitter-storm, he followed up with a second post, arguing, "Estimating is a way of buying knowledge. If having the additional knowledge will lead to different decisions, then acquiring that knowledge might be a good thing to do."

Mike added a proviso: that the cost of acquiring that knowledge doesn't exceed the benefit.

That’s the problem. Valid estimates can be expensive. Estimation accuracy often doesn’t get much better as more time and effort is expended - I've even seen accuracy get worse with more effort. For most of us, accuracy doesn’t improve significantly until our teams are experiencing estimating as truly tedious.

Our agile training has taught us techniques and insights that help us with the rough estimates. We do relative sizing, we estimate in points, we approximate in ranges, we divine other techniques to estimate more quickly, and we acknowledge that velocity not only varies dramatically from team to team but relies on team stability (and in fact must be re-derived and earlier estimates re-done if team make-up changes). And even with all that, we recognize the likelihood that our estimates will go wrong, so we negotiate at the beginning which side of the software triangle we're all willing to let slip (from scope/resources/schedule, the answer usually but not always is scope).

But the cost and pain of estimating still make us loathe to estimate long-term. We try to convince our customers to value the working code they’re getting every sprint and let go of the need for estimates.

But what we too seldom do is put a cost to estimating with accuracy. We too seldom give our customers a price to weigh against estimating's benefit. As a result, we continue to get requests for highly accurate up-front estimates accompanied by expectations that they’ll be delivered at low- or zero-cost.

Mike in his newsletter this month writes about how he puts the cost to bosses asking for dates: "I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver," he begins, "So long as the boss understands that information has a cost…. To add precision to an estimate requires time….

"If providing the estimate will cause all other work to stop for a week, the boss needs to understand that. If the boss has a true need for the estimate, he or she may be willing to let all other work stop. If the boss just wants an estimate to feel good or to hold the team accountable, the boss will probably settle for an easier-to-provide but less precise estimate. Information has a cost. If the person asking for that information is willing to pay that cost, you need to be willing to provide the information."

Mike concludes, "I don't always estimate. But it's a very helpful skill to become proficient at and is useful on many, perhaps most, projects."

We have to stop being reluctant to cite a cost for estimating, and instead educate our customers that estimating has a cost and ask whether the outcome justifies it. If it does, then we all need to negotiate what we’re taking off the table to make the time that accurate estimates require.


(Mike Cohn is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a co-founder of the Agile Alliance, and a co-founder and board member of the Scrum Alliance.)