“We are capturing actual hours so we can look back during the retrospective and look for ways to improve our estimations” or…

“We estimate until we achieve 5% certainty, and then we stop” or…

“We had our release plan worked out, but management wanted us to get more done, so they sent us back to provide better estimates.”

I hear this frequently and I cringe every time. The problem with all of these statements is that history has shown very clearly the only way to improve your estimations is to improve your definition (see The Cone of Uncertainty) and the only way to improve your definition is to start building (see “The Uncertainty Principle in Software Engineering“). Trying to create precise estimates without precise definition is a waste of time and money.

So, let me suggest something that may send many back to their college textbooks to prove me wrong….

In software engineering, estimation isn’t about knowing how long something will take to build, it’s about determining how complicated something is and then, through practical experience, seeing how long it takes to get it done. In other words, if I learn how long it takes me to do something simple, I can reasonably assume that a whole bunch of other “things” of roughly the same simplicity will take about the same amount of time. As I get better at determining relative simplicity (or complexity), I can make reasonable assumptions about how long harder things will take to do. We use Story Points and Ideal (Raw) Days as values to help us do this.

But why is software engineering different? Why can’t we just figure out how long it takes to build a screen or a database and just add it all up? The unfortunate news is that no task in software engineering is the same. Every time we change a line of code, we interject a behavioral change into a complex system, the result of which can NEVER be fully understood or anticipated. On the other hand, good production controls allow me, as an architect, to build a building or a bridge with very clearly calculated precision. The same steel I-beam will have carefully documented tolerances for heat, cold, and pressure that I can take advantage of every time I use that type of I-beam. This is NOT true for software engineering. The same line of code written in different places in the software can have radically different effects — effects that not only impact how you change that line of code, but will likely impact future planning as well.

We talk about comparing apples to apples and not comparing apples to oranges. Well, in software engineering, every line of code, every new function is a new type of fruit. You cannot easily compare lines of code or functions in a product and say that they would take the same amount of time to implement. The best way to create reasonably precise estimates is to create comparative estimates (how “big” this is as compared to how “big” that is), to do it against small pieces of work, and to write the software as you go in order to continuous improve your software definition. Invest time in Story Points (or similar simplified methods) and continuously refine what it is you plan to build.