Functional Safety

Estimation Safety Tips

By |

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 article I offer several safety tips to keep in mind as you prepare estimates for your project and for your individual work.

Tip #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 precisely defined 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 determines 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.

Tip #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 of course you must negotiate to reach some agreement. But don’t change your estimate simply because someone doesn’t care for 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 again: “Okay, 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 so you offered an alternative that might go over better.

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 (especially in Portland, where I live). 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.

Tip #3: The correct answer to any request for an estimate is “Let me get back to you on that.”

Avoid the temptation to give someone a quick estimate off the top of your head if you haven’t thought carefully 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 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.

This is a particularly common problem when processing requested requirements changes. A little impact analysis often reveals that the real request is substantially bigger than you might have thought based on the initial information you had available. So before you say, “Sure, no problem,” make sure you know what you’re getting into. Sometimes, providing a more realistic estimate leads the requester to drop the whole thing because it’s just not worth the cost or time required. It’s better to know that before you begin devoting effort on the activity, instead of getting halfway done and throwing out what you’ve already invested.

Tip #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 ten, fifty, or ninety percent confident that you’ll be finished within the estimated time? We usually don’t even think about that, let alone express it aloud. The person who receives the estimate probably assumes that you’re ninety percent confident in the estimate, even if you’re offering a best-case scenario. This mismatch can lead to unpleasant surprises when the estimate turns out to be vastly overoptimistic.

Alternatively, present an estimate as a range instead of a single value. Identify the minimum possible duration (or whatever measurable factor) for the work, the most likely or 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 the total by six. This results in a weighted average that reflects the probability distribution.

Unfortunately, the people to whom you present a range of estimates might select the lowest value of the range as the one they want to hear. A manager who goes with the minimum estimate has chosen to manage his project at a low confidence level, with only a small likelihood of delivering on project commitments. There’s no defense against unreasonable people who reject thoughtful estimates, but at least get into the habit of acknowledging the intrinsic uncertainty associated with all prognostications.

Tip #5: Incorporate contingency buffers into estimates.

Nothing goes exactly as planned. Therefore, build some contingency time into the estimate for each chunk of work you do. These contingencies will help you accommodate any unplanned tasks that may arise, and they’ll compensate for estimates that turn out to be too low. Contingency buffers also help you cope with risks that materialize into problems. If you don’t leave any slack in your schedule, the first unexpected situation you encounter will demolish your plans. Work to meet the nominal estimates, but commit externally to the estimates and the contingencies.

Contingency buffers are sometimes viewed as simply padding, a fudge factor to protect yourself in case you’re not very good at making estimates. Managers sometimes want to yank out the contingency buffer, assuming that this will somehow shorten the project. A manager who discards thoughtfully planned contingency buffers is making several assumptions:

• All estimates are perfect.

• No risks will materialize into problems.

• There will be no growth in the requirements.

• Nothing unexpected will happen.

Anyone who has ever worked on a software project knows that these are not very realistic assumptions. To help a manager avoid these terrible assumptions, you should point out some unexpected experiences from previous projects. Ask the manager if there is any reason to believe that the new project will be different and that none of those unpleasant experiences will be repeated. If no reason can be provided, then the contingency buffers should stay.

These five safety tips might not help you generate estimates that all of your managers, customers, and coworkers will dance to, but they will help you and your team at least hear the same music.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

 

Latest posts by Karl Wiegers (see all)