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 six safety tips to keep in mind as you prepare estimates for your project and for your individual work.
Estimation 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. Tutorials on how to estimate often are presented as though the body of work to be done is precisely defined and the goal of estimation is to determine the corresponding effort, cost, and time needed. Sometimes, though, estimation works another way. If some capability absolutely must be delivered by a particular date, then the estimator needs to determine how much functionality of given quality will fit into that time box. This is the premise behind sizing user stories in agile development and fitting them into a fixed-size sprint.
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 realistic likelihood of completing it by the dictated target date.
Estimation 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 body 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, you didn’t get any assistance, 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 here in Portland, Oregon). 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. You can examine assumptions, try different estimation methods, explore risks, or negotiate scope, resources, or quality. But don’t just cave to make someone smile.
Estimation 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 those who hear them. Before you provide an estimate, think through what all 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 requirement change requests. A little impact analysis often reveals that the real iceberg is substantially bigger than you 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 work, instead of getting halfway done and throwing out what you’ve already invested when the change turns out to be too big to justify.
Estimation Tip #4: Avoid giving single-point estimates.
Estimates contain uncertainty; that’s why they aren’t called predictions. When you provide an estimate, consider 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 ten-percent-likely, best-case scenario. This mismatch can lead to unpleasant surprises when the estimate turns out to be vastly overoptimistic. So share your thoughts about the probability of your estimate matching the real outcome.
Alternatively, present an estimate as a range instead of a single value. Identify the minimum possible duration (or some other 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 with this formula:
minimum value + 4 * (most likely value) + maximum value
Estimate = ––––––––––––––––––––––––––––––––––––––––––––––------
6
This results in a weighted average that roughly reflects the probability distribution.
Unfortunately, the people who receive your 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 predictions of the future.
Estimation 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 plus 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. However, 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 size of the project.
- Nothing unexpected will happen.
Anyone who has ever worked on a software project knows that these aren’t very realistic assumptions. To help a manager avoid these terrible assumptions, point out some unexpected experiences from previous projects. Ask if there’s any reason to believe that the new project will be different and none of those unpleasant experiences will be repeated. If there’s no good reason, the contingency buffers should stay.
Estimation Tip #6: Record actual outcomes and compare them to the estimates.
Perhaps you’ve heard that it’s a good idea to base our estimates on historical data. Someone asked me once, “But where do we get historical data?” Well, if you record what you did today, then tomorrow that is historical data. It’s not more complicated than that. So, get in the habit of recording your estimates and keeping records of what actually happened. This is the only way to improve future estimates. In fact, if you don’t do that, then the next time you’re not estimating, you are guessing—again.
If there’s a big discrepancy between forecast and reality, understand why and consider what you could do in the future to make better estimates for similar work. Were there some additional risk factors that you should consider the next time? Were you overly generous in your assumption about productivity? Did you overlook some task? Perhaps you could come up with a worksheet of tasks to consider for each such type of work.
For instance, people often forget about the need to plan some time for performing rework following a quality control activity such as testing or peer review. My experience, though, has been that there is almost always some rework to do, and it takes nonzero time to do it. So build rework tasks into your estimates, even if you don’t know just how much rework might be needed in a particular situation. As you collect data over time, you can begin to calculate some averages that will help you generate richer, more meaningful estimates for future work.
These six safety tips might not help you create estimates that all of your customers, managers, and coworkers will dance to, but at least they will help you and your team hear the same music.
Author: Karl Wiegers
Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of numerous books on software development, most recently Software Requirements, 3rd Edition (with Joy Beatty). He’s also the author of Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, a memoir of life lessons, and a forensic mystery novel, The Reconstruction. You can reach him at ProcessImpact.com or KarlWiegers.com.