“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.
More About #Estimating&Planning
Sprint Goals: Why the Plan Matters Less Than You Might Think
This information will help you take a BIG step toward having product dev, service, and support teams be self-managing. (Yes, really!)
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
How do you Plan for Support Time in a Sprint? #AskArtisan
Many Scrum Teams ask how to plan for support work in a Sprint. Can you plan the unplanned? There's no simple answer, but there IS an answer!
Can One Sprint Have Multiple Goals? #AskArtisan
Can you have more than one Sprint Goal in a single Sprint? I actually recommend it! In this video, I'll explain how it can improve Scrum team productivity.
How Are Product Goals and Sprint Goals Related? #AskArtisan
I'm often asked about Scrum goals; specifically Sprint Goals, Product Goals, and how they relate to each other. In this video, I'll tie them together for you.
What’s a Sprint Goal? #AskArtisan
Ever been out shopping only to get home and realized you didn't actually get what you needed? This is what happens to Scrum teams without a Sprint Goal!
What’s a Product Goal? #AskArtisan
The 2020 Scrum Guide introduced a new concept called the Product Goal, and many are still confused about the purpose and function of Product Goals.
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.
The Importance of Value to the Product Owner
Understanding outcome value isn’t just beneficial, it’s critically important. After all, delivering value is our priority!
Leave A Comment