Estimation Safety Tips

Software estimation is more of a dance than a science. To help you avoid tripping during the estimation waltz, Karl Wiegers presents five safety tips in this week's column. They might not help you generate perfect estimates, but they address estimation realities that might keep you out of trouble.

Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry we don't do a great job of estimation. In this column I offer several safety tips to keep in mind as you prepare estimates for your project and for your individual work.

Estimation Safety Tip No. 1: A goal is not an estimate. A management- or marketing-imposed delivery date is not an estimate--it is a goal. A team of a certain size and productivity level can produce only so much high-quality functionality in a given time. Estimation tutorials typically are presented as though the body of work to be done is predefined and the purpose of estimation is to determine the corresponding effort, cost, and time needed. Sometimes, though, estimation works another way. If the product absolutely must be delivered by a particular date, then the relevant estimation parameter is to determine how much functionality of given quality will fit into that time box. Commitments should be based on plausible estimates, not just desired targets. A piece of work should not be considered overdue if there was never any likelihood of completing it by the dictated target date.

Estimation Safety Tip No. 2: The estimate you produce should be unrelated to what you think the requester wants to hear. If your estimate and the requester's expectation are too far apart, then you must negotiate to reach some agreement. But don't change your estimate simply because someone doesn't like it. Suppose your manager requests a time estimate for some piece of work and you reply, "Two months."

"Two months?" exclaims your manager. "My grandmother could do that in three weeks with one hand tied behind her back!"

So you try a different estimate: "OK, how about one month?" What changed in those few seconds? Nothing! The task didn't shrink, and you didn't magically become more productive. Your manager just didn't like your first answer.

There's no reason to reduce a thoughtfully crafted estimate simply because someone isn't happy with it. We don't expect a rainy day to brighten up just because we feel like going on a picnic. Nor does it make sense to alter your own prediction of the future, barring a change in factors that affect how you think that future will turn out.

Estimation Safety Tip No. 3: The correct answer to any request for an estimate is "Let me get back to you on that." Avoid giving someone a quick estimate off the top of your head, because you haven't thought about the problem yet. You haven't really generated an estimate; you just pulled a guess out of thin air. Unfortunately these casual guesses often sound like commitments to your coworkers. Before you provide an estimate, think through what is being requested. Then assess how much time and effort it realistically would take to deliver on that request.

Estimation Safety Tip No. 4: Avoid giving single-point estimates. Estimates contain uncertainty; that's why they aren't called predictions. When you provide an estimate, also state your confidence in the estimate. Are you 10, 50, or 90 percent confident that you'll be finished within the estimated time? Alternatively, present an estimate as a range instead of a single value. Identify the minimum possible duration (or other measurable factor) for the work, the most likely or most expected value, and the maximum expected duration barring some catastrophic event. You can calculate a single, nominal-value estimate by summing the minimum possible value, four times the most likely value, and your maximum estimate for that work, and then dividing

Pages

About the author

Karl Wiegers, Ph.D., is the Principal Consultant at Process Impact in Portland, Oregon, and the author of Software Requirements (Microsoft Press, 1999) and Creating a Software Engineering Culture (Dorset House, 1996). You can reach him at www.processimpact.com. You can find more than 35 of Karl's articles at www.processimpact.com/pubs.shtml