{End Bracket}
From Bouncy Balls to Better Estimates
James Waletzky
Care to guess how many bouncy balls are in the container on my desk? You don't know the size of the balls, the volume of the container, or how full the container is, which makes an educated guess difficult. An estimate would be a pure stab in the dark. Does this problem sound familiar when applied to developing software? Let's explore the reasons why predicting the amount of development effort is extremely difficult early in a project, and what we can do to improve the accuracy of our estimates.
One type of estimate that we are often asked for early in development is a SWAG-or "Silly Wild-Ass Guess." A SWAG is a gut-feel estimate of effort to develop a software project. Project managers often ask for a SWAG to predict ship dates before we have suitable details on the requirements of our project, let alone any knowledge of the design. Your probability of guessing the number of bouncy balls on my desk is akin to estimating the amount of effort in a project with many variables.
As we remove uncertainty from the project by identifying features, detailing requirements, and creating a design, the picture becomes clearer. We may not have all the information required to make a precise estimate, but at this point we know what we don't know, and we can plan for the future. If I told you that the bouncy balls on my desk are one-half inch in diameter, sit in a container that could hold a loaf of bread, and the container is three-quarters full, your estimate of the number of balls in the container could be fairly accurate. With software projects, eventually we remove enough variability and minimize enough risk such that we can provide a reasonably accurate estimate. At the beginning of a project, however, there are many unknowns.
.gif)
(Click the image for a larger view)
Fortunately, there's a way to fast forward the process. My early-cycle development estimates have significantly improved since I discovered Wideband Delphi, an under-utilized team-based estimation technique that was popularized by Barry Boehm in the 1970s. A lightweight process, Wideband Delphi significantly improves the accuracy of estimates. Here is the process:
- Gather some people to help. Wideband Delphi recommends a team of two to five people. Bring in some people who have experience building a similar type of application, as well as some who have never built this kind of application. Multiple perspectives are valuable.
- Provide an overview of the work to be estimated. The person most familiar with the work gives the group a brief outline of the task at hand, focusing on requirements.
- Derive individual estimates. Every person in the room thinks about the problem and privately notes his assumptions. Then, on an index card, each person writes down his estimate in ideal effort-hours, and places it facedown on the table.
- Reveal the estimates and discuss assumptions. A facilitator reveals the anonymous estimates. What does everyone expect to happen here? The result is similar to multiple people guessing the number of bouncy balls on my desk without much information-estimates vary widely. A facilitated discussion about the assumptions that factored into the estimates ensues.
- Iterate from Step 3 until estimates match up. Each individual learns from the others in the room, updates his assumptions, and provides a new estimate. Estimates start converging. Continue this process until convergence is satisfactory.
Why does this technique work? Wideband Delphi incorporates the experience of others, is feedback-driven, allows estimators to go with their gut by keeping the first round anonymous, and facilitates learning. You quickly discover invalid or missed assumptions, while refining high-level requirements and design. The team agrees upon assumptions, documents decisions, and now has rationale for their numbers.
Wideband Delphi has substantially improved the accuracy of our estimates and decreased the risk in our projects by leveraging multiple minds to anticipate problems. For example, my team maintains a list of prioritized requirements from which we choose a subset to develop in a 30-day iteration. We use Wideband Delphi when we add requirements to this list to help us predict the size of work items and when we derive our detailed estimates for a development iteration. The end result has been on-time software deliveries and a better work-life balance!
For more information on Wideband Delphi and other estimation techniques, I recommend that you read Software Estimation: Demystifying the Black Art by Steve McConnell. It'll help you to deliver your software projects on time-or at least to improve the accuracy of your bouncy ball estimates.
James Waletzky is a Software Design Engineer in the Microsoft Engineering Excellence group. James focuses on improving engineering practices at Microsoft through training, consulting, and tools, while emphasizing continuous improvement.