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 the total by six. This results in a weighted average that reflects the estimate range.

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.

Estimation Safety Tip #No. 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 might arise, and they'll help 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 plus the contingencies.

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

These are terrible assumptions! To help a manager avoid these assumptions, you could 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 safety tips might not help you generate estimates with which all project stakeholders will be thrilled, but they will help you and your team deal realistically with what the future might bring.