Karl Scotland wrote an excellent blog post on Estimates as Sensors. In it, he extols the use of estimates to “sense capability and create feedback for yourself.” This is similar to my point in Estimation as Hypothesis.

At the end of this post, it now says “I don’t recommend using them to make promises and give guarantees to others.” Originally, this said something like “I don’t recommend using them to make promises and setting expectations of others.” I asked him what he did use for setting expectations. He had two responses. “I’d say expectations are set from understanding our capability, refined through sensing, and with a confidence range.“ and changing the post to reflect his original intent.

There’s more to this business of setting expectations.

First of all, when we uses sensing estimates to understand our capability, we’re setting our own expectations. We can be pretty ignorant of those capabilities if we’re not paying attention. And, as software developers, we’re usually paying attention to myriad other details rather than our own capability. I know I do.

Years ago, I had a project lead who asked me to estimate how long it would take to fix a reported bug in some code written by a colleague who’d since moved to a different project. I looked at the bug report and made a list of the changes I would have to make. Then I estimated how long it would take to edit, compile, and verify each of those changes. I handed this annotated list to the project lead. He took one look at it and said, “You can’t do any task in 10 minutes. It will take you longer than that to checkout the code, find the place to change, and check it in again. Never estimate a programming task at under 30 minutes.” That’s when I realized that I was only estimating part of the required work, the programming part on which I was focused, not the necessary parts that enabled the programming.

I’m pretty terrible at tracking my own capacity as an individual. Not only do I tend toward a narrow focus that excludes that, but I forget to track interruptions. An interruption already gives me two things to think about at once, but tracking it would be a third. That’s a lot for one brain. I do better when I’m part of a team. The nature of team work allows me opportunities to pop up to a larger viewpoint more easily. And within a team that’s worthy of the name, it’s easy to be honest about both the capability and the uncertainty concerning it.

Even as we gain a better understanding of our own capacity, how do we set appropriate expectations for others? This is the crux of many estimation conundrums. Most developers are used to low trust relationships with those asking for estimates. They’ve been burned in the past with estimates being treated as guarantees, with estimates being treated as initial positions for negotiations, with estimates being accepted without the conditions assumed for the estimates. Who hasn’t estimated how long some task would take and then be given another task to do in the same time?

If we know how our estimates are going to be treated, we can apply “fudge factors” or “Kentucky windage” to compensate. If we know our manager is going to cut our estimate in half, we may double the number we offer. Knowing that our estimate is going to be treated as a commitment, we may pad it for contingencies. Knowing that we’re going to be subjected to interruptions, we may extend it based on interruptions in the past. How much we pad depends on whether our estimate is expected to be at the 100%, 99%, 90% 80%, or 50% confidence level.

In fact, the padding tends to go up radically the higher the expectation for the estimate. These two measurements are also related to the consequences for missing it. When someone expects an estimate at the 100% confidence level, they’re outside the realm of the natural world. There is always the possibility of something completely unpredictable, a “black swan” in Taleb’s terminology. With that unreasonable level of expectation, people often couple it with a sense that if something does go wrong, someone should be punished. There’s no allowance for things outside of someone’s control.

There is always some things we don’t know, and some of those are things we don’t know we don’t know. A friend once devised Hughes Law: “On any boat maintenance project, there will be at least three unforeseen complications, at least one of which will follow this law.” He recommended taking your estimated time for the work, tripling the number, and incrementing the unit of time measurement. That two day job becomes 6 weeks. When we have an extreme level of uncertainty, then giving any number can make us nervous.

What if we were able to set expectations beyond a simple number? What if we could say what we know and what we don’t know? What if we could give our best estimate now, and give a better one next week when we know more? Would that help?

The thing is, these questions are not about the estimates. These questions are about the relationship between the person estimating and the person using the estimate. How can we improve that relationship?