What are we estimating, anyway?

Several schools of thought exist regarding the proper units to use when estimating work effort, especially on Agile teams. This article addresses what just may be “the simplest units that could possibly work” when estimating in order to provide predictability of development schedule.

When I first encountered what was called “Agile estimating” in 2004 or so, it was common to hear people talk about estimating user stories in terms of “size.” The emphasis was not on how long a user story would take, but rather on how big a story was. This seemed like a reasonable viewpoint, as it tended to de-emphasize duration, something that experience told me I’m not very good at assessing. (I tended to be overly optimistic.)

But as I attempted to put this emphasis on size into practice, I discovered that it was difficult to explain what “size” meant. I thought I had a grasp of it myself, but was generally unable to articulate what I meant by “size” to others on my team, and with whom I needed to engage in estimation activities. Often the best I could do was to define size in terms of what is was not (e.g. “it’s not duration” or “it’s not time, it’s size“).

Not satisfied with the inability to communicate clearly about this, I began thinking of and explaining “size” in terms of relative complexity. This was somewhat more satisfying, as the concept was easier to communicate, and my teammates and I seemed to be able to talk about this and use it. We decided that “less complexity” could be equated to “having fewer parts” and that “more complexity” meant “having more parts.”

This was fine as far as it went, but there were still some issues. It sometimes turned out that stories of supposedly equal complexity took substantially different amounts of time to complete, making the predicting of schedules less reliable. Order of story development played a part here. When two equally complex stories shared some underlying infrastructure, the first story to be developed would take longer than the second.

Some time later, I learned of other teams estimating in terms of what they called “effort.” This had a certain appeal, but seemed to raise old issues. Coming to agreement on what was meant by “effort” felt about the same as agreeing about the meaning of “size.” Effort is a slippery term, as it can refer to not only how long something will take, but also the ease with which that thing is accomplished. In other words, a user story that is easy (i.e. enjoyable) to work on may seem almost effortless, yet take more time to complete than a story that is difficult (i.e boring).

It could very well be that the appeal in using any of the above units, (size, complexity or effort) lies in our desire to avoid talking about estimates in terms of time. Perhaps we’ve convinced ourselves that we shouldn’t be talking about time, but about something (anything) else when estimating work effort.

But we should also remember why we’re estimating in the first place. If we’re estimating to provide predictability of schedule, then time is what we’re interested in. I’ll go so far as to state that while we’re not generally very good at estimating in terms absolute time, we’re much more adept at estimating in terms of relative time. (e.g. “I don’t know how long stories A and B will take to develop, but I do know that story A will take about twice as long as story B.”)

Given a choice of all the units described above, relative time may be “the simplest units that could possibly work.” They’re certainly more closely related to what we really want to know (absolute time), and they avoid the ambiguities that seem to be inherent in the other units.

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.