Another reason why estimations can’t work goes by the name of accidental complication. J.B. Rainsberger introduced this concept at Oredev 2013 .
The gist of the argument is this: every feature or functionality added to an existing project has two cost elements (what you want to estimate):
- Essential complication or g(e): How hard a problem is on its own. For example, implementing tax handling is hard, because the tax code is complex in itself. That is what J.B. Rainsberger calls essential complication or g(e).
- Accidental complication or h(a): The complication that creeps into to the work because – as J.B. puts it – “we suck at our jobs”. Or more diplomatically, the complication that comes from our organizational structures (how long does it take to get the approval for a new test environment?) and from how programs are written (no one is perfect, therefore some things need to be changed to accommodate the new functionality).
The cost of a feature is a function of both essential and accidental complication:
cost of feature = f(g(e), h(a))
In software, estimates of cost are often done by analogy. If features A and B are similar, then if feature A took 3 weeks, feature B will take 3 weeks. But then J.B. asks: “when was the last time that you worked on a perfect code base, where the cost of the accidental complication (how messy the code base was) was either zero or the same multiple of g(e) as when you implemented feature A?
He concludes – and I agree – that often the cost of accidental complication (dealing with organizational and technical issues specific to that code, and that organization) dominates (yes, dominates!) the cost of a feature. So, if h(a) is much larger than g(e) the cost of a feature cannot be determined by relative estimation – which is the most common estimation approach in teams that use, for example, Story Point estimation. What this means for you is: you can only determine the real cost of a feature by recognizing and measuring accidental complication, or –like I suggest in this book – by using the #NoEstimates approach.
Learn more about #NoEstimates
Don’t leave your deliveries to chance. Estimates are a percentage game, but we can improve our projects by orders of magnitude both in the value-delivery aspect as well as the “on time” delivery.
- Do you want to know more about how you can use NoEstimates to help you deliver your projects on time?
- Do you want to be able to predict progress for your projects every day, no need to bug others or spend time in boring estimation meetings?
- Join me and Woody Zuill in Helsinki for the #NoEstimates workshop.
If you have not yet seen the video don’t miss it!