Rules of Estimation

Estimation Considered Wasteful

Estimation, to predict some attribute of the future, is a common method tool. Estimation has long been a standard, some would say overused, tool in the tool box of most development teams. However, these last years estimation has been called out for questioning.

Estimation has always been problematic. One problem is that estimates are often perceived as promises, which they are not. They are only forecasts. Another issue is that estimates, just as weather forecasts, are often wrong. Putting too much weight on an estimate spells trouble. The majority of the criticism, though, does not focus on these problems, but instead on the inherent wastefulness of the practice.

I was recently part of an interesting session, arranged by Johannes Brodwall and Lasse Koskela, at the ØreDev 2009 conference, where we performed a “shoot-out” between some common, agile estimation techniques. The ensuing discussion got my brain started and at the end of the session I blurted out a suggestion for the “Rules of Estimation”, which everyone seemed to like. These were also inspired by Michael Jackson’s wonderful “Rules of Optimization“. So here they are, in a slightly enhanced form. First the rules, then the explanations.

Rules of Estimation

  1. Organise the work to make estimation superfluous.
  2. (If avoidance is not possible) Do estimation quickly, relatively, iteratively, in collaboration, and with as little precision as allowed.
  3. (For experts only) Do estimation in a blink, using gut feeling.

Or in shorter form:

  1. Avoid it
  2. Do it (if you must)
  3. Feel it (for experts only)

Explanations

1. Organise the work to make estimation superfluous

There are pretty clear indications that estimation often is wasteful. By wasteful, I mean it does not add value to the customer. No customer ever ordered an estimate. Some people may regard it as “necessary waste”, work we need to do to perform the really important work, but Toyota and Lean has shown us that this is actually a fallacy. We are capable of organising our work to make estimation unnecessary.

To be clear, I am not talking about breaking down large tasks to smaller tasks to understand them. Also, I am not talking about discussing the need or ROI of a certain feature, nor designing a possible solution to these needs. I am simply talking about the act of estimating for the purpose of guessing how “big” something is.

If you think about it, the only objective of estimation is to give a basis for some kind of promise. For example, we may estimate a project to be able to offer our service at a fixed price (a promise). Hence, if you are able to organise your work in a way that promises are not needed, you may save yourself the time and the energy of estimation work.

Examples of techniques that help eliminate the need for estimation are supply chaining, i.e. close collaboration with suppliers thereby removing the need for scoping contracts with attached deadlines, active maintenance, i.e. the marriage of business and IT in a continuous business development activity, thereby removing the notion that one part is a customer and the other a supplier even though both work for the same company, and Kanban, part of which involves working without iterations, thereby eliminating the need for committing (promising) during iteration planning.

There are certainly occasions were some estimation is beneficial, for example to coordinate a large marketing campaign with a major product release, but these cases are outliers and may be handled in a much more agile way than is standard practice today.

To work without the need for estimation is the route that should be preferred and we must insistently strive to get there.

2. If avoidance is not possible, do estimation quickly, relatively, iteratively, in collaboration, and with as little precision as allowed

For some situations, and for most teams today, avoiding estimation is simply not feasible. Some developers are caught by sales people to make off-the-cuff project estimates for their next tender. Most developers estimate projects, even if done in-house. Even agile teams estimate, for release and iteration cycles. While you are working on the cultural change of removing unnecessary work you have to estimate.

If you must estimate, then I suggest you do the work with these principles in mind:

  • Quickly, using simple tools. It is pretty obvious that we should at least keep wasteful work to a minimum.
  • Relatively. Estimate the size of each item in relation to other items. Then, derive the length in time as soon as we know the duration of a few items, as suggested by Mike Cohn. This is a self-correcting, ego-free system.
  • Iteratively. Estimate several times, with additional information and justification of estimates between rounds. This page lists some scientific research that support collaborative, iterative estimation.
  • In collaboration. The best estimates are made by more than one person, preferably a team coming from different perspectives (cross-functional).
  • Imprecisely. Use as little precision as you are allowed. It is more important that the estimate is correct rather than precise. “In the future” is a better answer than “Oct 2” if you really have no clue when you’ll be done. Use a range and a unit that communicates the level of uncertainty you experience.

3. (For experts only:) Do estimation in a blink, using gut feeling

As I am sure the reader can tell, the second route is a lot of work. It is also a difficult and treacherous path that may lead you horribly astray. Anyone who has been in a fixed-price project that is overdue knows what madness that may surface in these stressful circumstances. But there is actually one pretty powerful short-cut: Use experienced experts.

If you can get a number of experts in the same room, estimating in collaboration using the techniques mentioned above, the estimation may be done quite quickly. These expert can tell in a blink, using questions and gut-feeling, if this is going to be a three-week, three-month or a three-year project. How this works is really a little bit outside of what we know, but “intuition” or “pattern matching” can be quite trustworthy in these cases, see “Blink”, by Malcolm Gladwell.

The first caveat to this is that they would have to be true experts. They must be seasoned veterans (at least 10 years of experience in the field) that have performed similar work in the past.

Another issue is that they may not be willing to do it, often for good reasons. If you have questioned their estimates in the past, or passed on the consequences of a missed forecast to them, they will certainly be suspicious of your intentions.

Conclusion

To conclude, I believe we are better off viewing estimation as a wasteful practice. Since it is wasteful, we should strive to organise our work to make estimation unnecessary. If that is not possible at this time, perform estimation as quickly, simply, and cleverly as possible. Always remember that estimation is a forecast, not a promise. Communicate that uncertainty in the estimates. Using true experts is a powerful way to make good enough estimates in an efficient manner.


3 thoughts on “Rules of Estimation

  1. Nice post. I hope you’re not posting in English just for me! Isn’t there a case where you’d need to know how big a possible project is to know whether it is even worth starting? Or is that covered by your disclaimer in Rule 1?

  2. Thanks, Chris! All for you, of course. 🙂 I mean, after having read a blog in Swedish using Google Translate for a few years I think you would be entitled to it.

    Your question: It _could_ be covered by the disclaimer. It depends on if a project is really needed? But by organising work in _projects_, already there you have not organised to remove unnecessary work, at least if this concerns product development. Would it be possible to do it continuously instead? At different intensity levels depending on need, of course. To have a long-term _product_ focus (instead of project focus)?

    Everything are projects nowadays. It doesn’t need to be. If you removed the artificial project end-points, very little or no estimation would be necessary, I think.

  3. I’m just in the middle of, or somehow have a chance to influence the budget and planning process in a project like situation, not explicitely called a project at all times – more often called a product/business support. We’re planning to have our first sprint planning this week making our first coarse estimate.

    This article gives me something to think of!

Comments are closed.