“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.

FEATURED RESOURCE:

FEATURED RESOURCE:

Guide to Scrum Estimation

Swipe this FREE DOWNLOAD for the key points of PBI estimation.

Normally available ONLY to Artisan students, we’re offering this handy guide to you for a limited time!

More About #Estimating&Planning

Sprint Goals: The Key to a Well-Executed Sprint

Sprint goals are key to a successful Sprint. They help keep the Scrum team on track and moving together in one direction. Without Sprint goals, the Scrum team can easily lose focus and get sidetracked. In this blog post, we'll discuss what sprint goals are and how they can help your Scrum team stay focused

What is Scrum?

The most popular Agile Development framework, Scrum, can be explained in many ways. If you're just trying to understand what Scrum is, this post is for you.