The Illusion of Precision

4 February 2011

Jim Schiel
Artisan Software Consulting LLC

For me, one of the most intriguing, yet not explicitly stated, fundamentals of Agile
Development is the practice of analyzing and designing just enough of what we are planning to build that we can then move forward to build it. You can find specific examples of what I mean in the practices of story slicing1 and backlog grooming2 and in the concept of vertical, functional slices. This fundamental concept, that it is generally more effective to “understand a little, build a little, understand a little more, build a little more,” created an eye-opening conversion for me when I finally, truly understood it.
However, in understanding the concept, I find myself struggling with another question:

Why do so many of us continue to spend the effort and money to create overly-precise estimates (in specific hours or even fractions of hours) for features that cannot be precisely defined, no matter how much we might wish it to be so?

Consider these two statements:

1. The tensile (yield) strength of ASTM A36 structural steel is 250 MegaPascals.

2. To achieve proper aesthetics in the standard Cape Cod-style home, use 12 gallons of light brown paint on the exterior of the house and 20 gallons of eggshell paint on the interior walls of the house.

In statement 1, we have a very specific description of a material (A36 structural steel) and a clear and precise measurement (250 MPa) of a specific quality (yield strength).Assuming your customers understand what A36 steel is, they can all agree as to the specifics of the materials. No matter what you do and no matter what you build, A36 is A36.

However, in statement 2, we want to achieve “proper aesthetics” of a “standard Cape Code-style home.” What is “proper aesthetics?” What is a “standard Cape Code-style home?” Will all of your customers agree to the exact same definition? Once you start painting the house, is there a possibility that the definition of “proper aesthetics” may change? Considering the possibilities, would you be willing to COMMIT to the 32 gallons of paint? Would you buy all of the paint up-front and start painting?

Unfortunately, for many in software engineering, the answer is yes. We mistakenly make (or are forced into making) these types of commitments every day. We find ourselves creating precision where precise definition does not exist, and then paying the price when we are wrong. Worse, we frequently shift the risk and cost of changing requirements to our customers by asking for “change requests,” often creating a compromised relationship at best.

In nearly all cases of feature development, the truth is simple -- even our customers frequently don╩╝t know what they want until after we start building it.

In an agile approach to statement 2, I would roughly estimate 30-40 gallons of paint but would begin by buying only a couple gallons of paint and painting one of the exterior walls. We could then ask our customer to examine the work. When the customer decides to make changes to the work, we can easily adjust our approach, refining our estimates and purchasing more of the proper paint colors. As we get closer to the completion of our work, our estimates get more precise because we have a clearer description of what the customer wants (ironically, the customer is also getting a clearer description of what they want). By the time we finish the paint job, the customer has gotten exactly what they wanted -- even if it╩╝s different than what they imagined at the onset.

In software today, the user experience is much more important, more complex, and more fluid. While our customers often have a basic idea of what they want to do, they have very little clarity on exactly how they want it to look or feel. Under these conditions, once cannot create precise estimates of work. I generally recommend backlog grooming sessions during the Sprint in order to engage in a form of “progressive elaboration,” learning more and more about what╩╝s coming in the next Sprint. As a result, at Sprint Planning, Scrum teams can focus on how they are going to build something, rather than trying to focus on what it means.

Scrum╩╝s built-in “inspect and adapt” feedback loops are there precisely because the realization of customer requirements (and thus the direction we take in building software) is emergent. To be successful, our estimation practices must reflect a similar trend from imprecise to more-precise as our understanding improves. Practices such as “story point estimation3,” “story slicing,” and “backlog grooming” are important, if not essential, steps in that direction. How we deal with our customers in this type of environment must also change, but such discussion is beyond the scope of this article.

Consider, therefore, that story estimation is more associated with the aesthetics of form and style than the mathematics of tensile strength. Such aesthetics do not lend themselves to precision and mathematical treatment. Instead, they beg to be approximated, suggested, and then built and refined, to emerge from the imagination, slowly and carefully, until they are complete.

1 See www.artisansoftwareconsulting.com/page.php?page=Story%20Slicing
2 See www.artisansoftwareconsulting.com/page.php?page=Backlog%20Grooming
3 See www.artisansoftwareconsulting.com/page.php?page=User%20Stories


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Rajesh Singh, CSM, 9/19/2011 3:20:17 PM
Jim,
I agree with your view on estimating Stories... however, there is definitely a need of mindset change (not only of developers but also PM and senior management) to the whole estimation this way - as most of the time, they think team gives conservative estimate and so, going this new route of estimation would make things worse, when it comes to perception.... but, I want to tread this path as I am definitely for it....

(it was great to spend 2 days on ScrumMaster training from you, in San Jose, on 9/15, 9/16)

You must Login or Signup to comment.