----------------------------------------
For many software development professionals, estimation is at best a necessary evil and at worst a hiss and a byword. Here’s a sample conversation in which time is estimated for a software project:
Bob approaches Joe in the hallway just outside the break room.
Bob (Project Manager): “Hey, Joe! How’s it going? Say did you have a look at those requirements I sent you? How long is that going to take, do you think?”
Joe (Developer): “Hi Bob. Well, it’s hard to say. There wasn’t a lot of detail in your email.”
Bob: “Yeah, we’re still fleshing things out. Management just wants an idea of how big this thing is before we commit resources to it. What do you think? Three, four months?”
Joe: “Umm, maybe. I’d have to figure out some of those integration points and . . .”
Bob: “Great! Don’t worry, I won’t quote you. I’ll just let management know it’s doable.”
You know what happens next. The three-month “estimate” gets etched in stone, and Joe’s feet are raked over the coals when the project runs “over” by an additional three months. Poor, poor Joe. If you’ve ever been in Joe’s shoes, know that you aren’t alone and all is not lost. Here are some best practices that you might use to create accurate estimates and communicate them properly to your stakeholders.
- Don’t provide off-the-cuff estimates: An off-the-cuff estimate is any estimate created without any research or rigor of any sort, a la Bob and Joe’s three-month estimate. Also known as a “guesstimate” or a hallway estimate, this kind of estimate is both dangerous and professionally irresponsible. The first estimate you provide will be the one that is most remembered and the one to which all other estimates will be compared, so you’d better make it a good one!
Rather than going with your gut, tell the requester that you don’t have an estimate right now, but you will have something for them in about 15 minutes. Then get to work making a real estimate that’s based on something tangible. - Don’t provide a single-point value: Provide a range—such as best, most likely, and worst case—to express the variability and level of confidence you have in your estimate. Early in the project, when requirements are still written on the back of a napkin, you simply don’t have enough information to provide a highly accurate estimate. So rather than providing an estimate of exactly six months (six is a single-point value), give an estimate of four to twelve months, with four being the best-case scenario and twelve being the worst. Not only does this communicate the effort and size of the project, but the range also expresses how confident you feel about it. This will naturally lead to productive discussions including what you need to increase the accuracy of your estimate.
- Make the precision of your estimate match its accuracy: In How to Lie With Statistics, Darrell Huff says, "[T]he ever-impressive decimal . . . can lend an aura of precision to the inexact” (p. 109). If you feel that your estimate is exact, then by all means, say that it will take you “3.25 days.” But if you aren’t confident that the task will be completed at 10:00 a.m. on the fourth day, then provide a more inexact estimate, such as “three or four days.”
- Don’t deliberately underestimate: As a project lead, you may be tempted to think the estimates your engineers have provided contain some unnecessary padding. Unless you have data that support this theory, you will almost certainly regret intentionally shrinking their estimates. For one thing, the estimates you have are probably already too low because as an industry, we almost invariably underestimate our projects. And secondly, in both cost and schedule, the penalties of underestimation are far greater than the penalties for overestimation.
- Count, compute, and use judgment: Finally, use this process to create your estimates: Count something, compute an estimate, and use judgment as a last resort. For example, let’s say you are in a large hall filled with people. Everyone is seated at one of many tables that are arranged in rows. A man near the front of the hall stands up and issues a challenge to the group. “Please estimate the total number of children who belong to the individuals in this room,” he says. “You have five minutes.” At first glance this may seem like a daunting task, but if we use our estimation technique of Count → Compute → Use Judgment, then it becomes fairly easy to make our estimate.
First, we count something. In this example it makes sense to count the number of individuals in the room. Not only does this value have a strong correlation to what we’re really after (a number of children), but it’s relatively easy to count and it’s readily available.
Next, we use our count of individuals to compute an estimate for the number of children they have. We need only a bit of data to make such an estimate. Assuming that everyone in the room is an adult, all we need is a metric such as the national average of children per adult. Obviously, if we have demographic information about the group inside the room (age, race, sex, social status, affluence, etc.) we could select a better metric to use in our computation. But the principle is that we combine our count with our metric to arrive at an estimate that is plausible, fact-based, and defensible. We use our own judgment as a last resort if all else fails.
The point is that with a little bit of data on the current project (your unit of measurement) and a dash of data collected from historical projects (average hours per unit of measurement), you can calculate accurate estimates.
Give one or more of these best practices a try. At best, you’ll revolutionize your organization’s estimation and planning processes and be recognized as a hero. At worst, you’ll never again be asked to explain why your team didn’t meet your initial estimate of “Umm, maybe.”
Additional Reading:
- Software Estimation: Demystifying the Black Art by Steve McConnell
- Estimating Software-Intensive Systems, by Richard D. Stutzke
- Agile Estimating and Planning, by Mike Cohn
