Estimating and Scheduling for Dummies

Part I - Estimating

The For Dummies series started in 1991 with "DOS for Dummies" and quickly gained popularity. Now with more than 125,000,000 books in print, the For Dummies series caters to everyone’s needs. Some of the bestselling titles include "Dating for Dummies", "Shakespeare for Dummies", “Feng Shui For Dummies", and yes, “Politics for Dummies” - the book that claims to help you sift through all the babble to get to the truth!

If a For Dummies book can help us understand a topic as obscure as politics, maybe its time someone wrote a For Dummies book on Estimating and Scheduling for Software Projects. Why? Because of all the things we do on software projects, by far, estimating and scheduling is the thing we do the worst. Every software company has war stories of failures resulting from inaccurate estimates and unrealistic schedules. With all of this experience to build on, you would think that we would learn from our past mistakes. Well, it seems that we haven’t.

The amazing thing about this topic is that it’s not rocket science! People have been estimating and scheduling tasks for hundreds, maybe thousands of years. Yet, we in the software industry have managed to take something that is done well in other industries and screw it up to the point where we often just give up in disgust.

Think about this:

• Many estimates for software development projects are derived from hunches, guesswork, and gut instincts. 

• We say things like “that should take about 2 weeks” without any data to support the estimate. 

• We set schedules based on bad estimates without adjusting for past inaccuracies in estimating. 

• We don’t bother to keep track of the actual time it takes to complete a task. Without this key piece of information, our estimates can never improve.

• Management frequently over-commits and makes unreasonable promises to customers, putting more pressure on the organization to make meaningless estimates and unrealistic schedules.

This month, we look at ways to improve the accuracy of estimates. Next month, we’ll continue this discussion with a look at ways to develop realistic schedules.

Estimates, Targets, Commitments, and Schedules

To begin the discussion on estimating, we need to start with some definitions. Steve McConnell says that:

• “A good estimate […] provides a clear enough view of the project to allow the project leadership to make good decisions about how to control a project in order to hit its targets.” [1]

If you have good estimates, project managers can make good decisions about how to control the project so that you are more likely to meet, or come close to meeting, the project’s targets and commitments. (We’ll define these new terms in a bit.) Okay, so what is a good estimate?

• An estimate is good if it is within X% of how long it actually takes to do the work.

You can decide how good the estimate needs to be based on risk to the project. Clearly, for some parts of a project, estimates may not need to be as “good” as for others.

An important point about estimates that most people don’t understand is that:

• Estimates are never negotiable. [1]

What does this mean? Well, consider this - it takes about 9 months to have a baby. This estimate is based on physiological data and a whole bunch of personal experience. There’s not much we can do change it. It’s not negotiable!

One last point about estimates:

• Good estimates can only come from good requirements …

If your projects suffer from poorly written, ambiguous requirements, you have no hope of getting better at estimating. Starting with well-written requirements is the first step.

Read more about writing good requirements…

Steve McConnell [1] defines targets as descriptions of desirable business objectives that are determined by making business decisions. Targets are internal to the business.

• Unlike estimates, targets are always negotiable. [1]

Steve McConnell [1] defines commitments as promises to deliver defined functionality at a specific level of quality by a specific date. These are promises made specifically to customers - be they internal or external.

• Like targets, commitments are always negotiable. [1]

Steve McConnell [1] defines schedules as a list of a project's terminal elements with intended start and finish dates. Terminal elements are items that are estimated in terms of resource requirements, budget and duration, and are linked by dependencies.

• Like targets and commitments, schedules are always negotiable.[1]

An important point to remember about schedules:

• Good schedules can only come from good estimates…

Learn more about accurate estimating and scheduling techniques…

Now that we have defined these terms, let’s discuss some ways to build good estimating skills.

Building Good Estimating Skills

Karl Wiegers said that:

“There are several ways to become a better estimator. The most basic approach is to record effort, duration or size estimates as well as your estimating processes and assumptions, and then record the actual results from each estimated activity. Comparing actual outcomes to the estimates helps generate more accurate estimates in the future. Estimating procedures and templates that itemize tasks help avoid the common problem of overlooking necessary work.” [2]

Just like anything else, some people are better at estimating than others. These folks have mastered a few basic skills that allow them to make good estimates. What are these skills? Here are some examples:

• Compare actuals and estimates -

The simplest and quickest way to improve your estimating skills is to keep track of the actual time it takes to complete tasks. When a task is completed, compare the actual time with your estimate and reconcile the difference. Ask yourself:

• Why did it take longer to complete this task?

• What did I not know about this task when I made the initial estimate?

• Use expert judgment -

Simply put, this means asking people who have done an activity many times in the past. If you’ve never written a device driver before, you might want to talk to people who have, before committing to an estimate.

• Analogous estimating -

Compare the task to be estimated with previously completed tasks of the same or similar type. If you have recently completed a task (say testing a particular part of an application) and someone asks you how long would it take you to test a similar part of another application, you have some analogous experience upon which to base your estimate.

• Parametric estimating -

Some tasks are very similar. For these, parametric estimating can be used to estimate the work. Multiply the quantity of work to be performed by your productivity rate.

For example, if you are developing a bunch of widgets for a GUI and you know from past experience, it takes you x hours to develop a widget, you can use that information to estimate how long it will take to develop all of the widgets.

• Three-Point Estimates -

With this method, you create three different estimates – a most likely, optimistic, and pessimistic estimate. Create a final estimate by averaging the three estimates.

Here’s an example: testing a new build for an application would most likely take you 14 hours. If you don’t find any showstoppers ( optimistic), then testing will take 12 hours. If there are many showstoppers ( pessimistic), testing could take up to 24 hours. So your final estimate is the average of the three or (14+12+24)/3=16.7 hours.

• Consensus-based Estimating -

Consensus-based estimating is yet another excellent technique for improving the accuracy of estimates. This technique uses a small group of experienced people to estimate a task that is relatively new. The most popular example of a consensus-based estimating technique is the Wideband Delphi Method. [3] Originally developed by the Rand Corporation, this technique can lead to reasonably good estimates for tasks that are new.

Here’s how it works:

• Several experienced people are given the problem statement and separately estimate how long it would take them to complete the task – assuming they could work on the task uninterrupted.
  
  
• When everyone is done, the group comes together with a facilitator and everyone’s estimates are plotted on a simple chart.

• The wide variance in the estimates is directly related to differences in assumptions made by each person.
  
  
• The assumptions made by each person are listed and discussed. A list of assumptions is agreed on
  
  
• The same team then goes off on their own for the second round of estimating using the new list of assumptions.
  
  
• The group reconvenes and everyone’s estimates are plotted again. This time it might look like this…

• After just two rounds, the estimates start to converge. This process can be repeated until the desired “goodness” (as measured by the variance) of the estimate is achieved.

Summary

Bottom line - to get better at estimating, you need to track the actual time it takes you to do the work, compare your estimate with the actual time and reconcile the difference. Measure the goodness of your estimates to see if you are getting better. Remember:

Good estimates are supported by data not by hunches.

Good estimates can only come from good requirements.

Only by starting with good estimates can we have a chance at creating realistic schedules that we can meet. More on schedules next month…