The #NoEstimates debate should be about finding the break-point

In a recent Article about the #noestimates movement, the author said, that the preambles of #noestimates may be wrong. He stated, that he cannot imagine how to bid for a project, since without estimating, he cannot answer the most basic questions of a client:

  1. How much money (s)he needs to spend to get the work done ?
  2. How less or more I’m quoting as compared to other bidders ?

I agree on the clients want certainty thing, shining through these questions.

Later on he compared building software with buying a car, or even more simplified: deciding between two different brands — Honda and Mercedes — while having a fixed budget.

Buying cars not the same as writing software


Deciding between two existing (already built) options while having fixed and prioritized needs (requirements) and a — more or less — fixed budget, is different from most, if not all software development projects, where needs change throughout the project, which is a well known fact, backed by several studies & research (especially in Web Development, see e.g. DOI 10.1007/s00766–002–0153-x)

In that case the estimation itself inherits huge amounts of uncertainty (or risk) and therefore the value of estimates declines quickly. Sure, it may be feasible to put more effort in estimating, analyzing data of past, similar projects, etc.
But with rising uncertainty of requirements (and conceivably technical environment) and rising effort to estimate, there’s a break-point, where further raising the certainty of estimates yields that much effort (or becomes even impossible), that it may be better to just start building.

Sure, that doesn’t tackle the initial problem that clients want certainty upfront. On the other hand, if that need cannot be fulfilled — and it can’t if requirements and technical environment are highly volatile — it may be better to deliver as much value as possible within a given budget — in an incremental, iterative way, with fast feedback loops, managing the budget “on the go”, while reducing estimation effort (that could be called waste in that case from a Lean perspective).

So, from my point of view, the whole debate should better be built around the question:

Where’s the break-point?

If possible, I’d always prefer to give a client that upfront certainty she desires — certainty is by far easier to sell than uncertainty.

Assuming this holds true, we should look at all the variables that influence the ability to estimate and the effort needed to make them certain:

  • Team maturity and experience — in general and in the domain of the project;
  • availability of data from, preferably similar, past projects;
  • stability of the technical environment;
  • confidence that the requirements are complete, as well as
  • likelihood of changes of the requirements and their impact on the project as a whole (architecture, components, etc.).

Unfortunately, I cannot provide a formal method or mathematical model, but if you look at these dimensions and still believe you can provide (quite) certain estimates with reasonable efforts, do it.

If not, talk to your client, tell him about the correlation between all those dimensions, the certainty of estimates (yours and your competitors), try to convince her, that — given the current situation — the need for certainty is virtually impossible to fulfill and that it would be better to follow a agile, lean, incremental, iterative, fast-feedback (whatever) approach, including reduced upfront estimation, but strong budget-management throughout the project.

Closing thoughts

Instead of thousands of opposing tweets, hundreds of articles, dozens of papers and presentations, it would be better to join forces and build a valid decision model for #(no)estimates.

Both approaches have their domain, where one or the other is suited better. In my domain, web development, I’m quite sure clients would benefit from estimating less, yet it’s hard to convince them, since most of them don’t have a clue and don’t care about this whole debate — which is perfectly fine, of course.

Therefore, I’d like to have a simple, yet solid model, helping me to decide which approach to take and a (even simpler one) helping me to convince my client, that the direction I’ve chosen, is the best for his/her needs.

(If such model already exists, drop me a line. I’ll be happy to learn and improve.)