Over a million developers have joined DZone.

Setting Expectations

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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?

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of George Dinwiddie, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}