Chapter 8—Estimation
An accurate schedule estimate is part of the foundation of maximum development speed. Without an accurate schedule
estimate, there is no foundation for effective planning and no support for rapid development/
Coming up with a perfect estimate doesn’t do any good if you can’t get the estimate accepted.
I.
The Software-Estimation Story
1. When constructing software, you can’t tell exactly how much it is going to cost until you know exactly what “it” is.
2. If you want to build to a budget, you have to be very flexible about the product characteristics.
3. Whether you build to a budget or not, software development is a process of gradual refinement, so some imprecision
is unavoidable. The only way to refine the product concept and thereby the estimate is to actually build the software.
4. Estimates can be refined over the course of a project. Promise your customer that you will provide more refined
estimates at each stage.
The basic software-estimation story is that software development is a process of gradual refinement. You begin with a
fuzzy picture of what you want to build and then spend the rest of the project trying to bring that picture into clearer focus.
Software development is a process of making increasingly detailed decisions. You refine the product concept into a
statement of requirements, the requirements into a preliminary design, the preliminary design into a detailed design, and
the detailed design into working code.
Most software customers initially want more than they can afford. This means they have to bend either their ideas about
the product or their ideas about the resources they are willing to commit.
Software builders face a choice between estimation accuracy and project control. If you can be flexible about the product
characteristics, you can have some control over cost and schedule and can “build to budget”.
Help your customers by telling them about the parts of the project that you are able to estimate. Tell them where the next
landmark is.
If customers want the shortest possible schedule, they should not pressure you to lower your estimates or to provide them
with misleadingly precise estimates.
An estimate that is either too low or too high will result in a longer-than-optimal actual schedule.
Shortest-possible software schedules are achieved by creating the most accurate estimates possible, not the most
precise.
II.
Estimation-Process Overview
The process of creating an accurate development schedule consists of three steps:
1.
2.
3.
4.
III.
Estimate the size of the product (number of lines of code or function points).
Estimate the effort (man-months)
Estimate the schedule (calendar months)
Provide estimates in ranges and periodically refine the ranges to provide increasing precision as the project
progresses.
Size Estimation
You can estimate the size of a project in any of several ways:
1. Use an algorithmic approach, such as function points, that estimates program size from program features.
2. Use size-estimation software that estimates program size from your description of program features (screens, dialogs,
files, database tables, and so on).
3. Estimate each major piece of the new system as a percentage of the size of a similar piece of a similar project.
A. Function-Point Estimation
See class lectures.
B. Estimation Tips
1. Avoid off-the-cuff estimates
2. Allow time for the estimate, and plan it
3. Use data from previous projects
4. Use developer-based estimates
5. Estimate by walk-through
6. Estimate by categories
7. Estimate as a low level of detail
8. Don’t omit common tasks
9. Use software estimation tools
10. Use several different estimation techniques, and compare the results
11. Change estimation practices as the project progresses
C. Estimate Presentation Styles
The way you present an estimate initially can have a huge impact on what happens when the estimate needs changing
later. Software estimation usually involves a great deal of risk and uncertainty, and a good estimate captures that risk and
uncertainty.
Some techniques for presenting schedule estimates:
1. Plus-or-minus qualifiers
2. Ranges
3. Risk quantification—when you document the sources of uncertainty in your estimates, you provide your
customers with information they can use to reduce the risks to the project and you lay the groundwork for
explaining schedule changes if any of the risks materialize.
4. Cases—present your estimates for best case, worst case, planned case, and current case.
IV.
Effort Estimation
You’ll need an effort estimate in order to know how many people to pout on your project; and having an effort estimate
makes it easy to derive the schedule estimate.
Some ways to convert a size estimate into an effort estimate:
1. Use estimation software to create an effort estimate directly from the size software.
2. Use the schedule tables in Chapter 8
3. Use your organization’s historical data to determine how much effort previous project of the estimated size
have taken.
4. Use an algorithmic approach such as the COCOMO model to convert a lines-of-code estimate into an effort
estimate.
V.
Schedule Estimation
Some alternatives
1. Schedule in months = 3.0 * man-months1/3
2. Use estimation software to compute the schedule from your size and effort estimates
 Use historical data from your organization
 Use schedule tables
Using one of the above alternatives and a periodic refinement approach allow you to quit using padding.
An estimate range with periodic refinements says, “The estimates are good, but it’s not possible for an estimate to be
precise at this stage in the project. It will become more precise as we go along.”
A. Commitment-Based Scheduling
A few organizations proceed directly from requirements to scheduling without creating intermediate effort estimates. They
typically do so within a commitment-based culture in which each developer is asked to make a schedule commitment
rather than a schedule estimate. Advantages of this include: (1) It increases developers’ buy-in to schedule (2) it tends to
result in high morale for the period immediately following the commitment, and (3) it tends to elicit a lot of voluntary
overtime from the developers. Weaknesses include (1) developers’ estimates tend to be optimistic, which results in
estimation errors.
Commitment-based planning as it is commonly practices does not help to achieve short schedules.
B. Jones’s First-Order Estimation Practice
Uses an adjustment of the function point size-estimate.
VI.
Ballpark Schedule Estimates
+One of the toughest obstacles to meaningful software scheduling is that usable, concrete information about software
scheduling is hared to come by.
Uses schedules to develop estimates that are better than gut instinct.
You can reduce overall project cost by lengthening the schedule and reducing the team size.
Line-of-code measurements have come under attack, and some people suggest using “function points” instead.
Be sure that your planned schedule is at least as long as the shortest possible schedule in a table. Anything shorter is an
impossible schedule!
Shortest possible schedules
Assume:
1. Your team has drawn its talent from the top 10 percent of the talent pool
2. The project has ideal project management
3. Advanced software tools are available
4. Developers have unlimited access to computer resources
5. The office environment is ideal
6. The entire project team is located within the same immediate area
7. All necessary communications tools are integrated into the work environment
8. Supplemental communications technologies are available when needed
9. The most time-efficient development methods and development tools are used
10. Requirements are completely know
11. Requirements don’t change
These schedules have been compressed as much as possible
Two facts of life
1. There is a shortest possible schedule, and you can’t beat it. At some point, adding more developers slows a
project down.
2. Costs increase rapidly when you shorten the schedule below nominal.
Most researchers have concluded that it isn’t possible to achieve a schedule compression factor lower than about 0.75 or
0.80. What this means is that there is a limit to how much you can reduce a schedule by adding people and requiring
more overtime. Also, if you’re willing to lengthen your schedule slightly, you can reduce the cost of your project by
reducing the team size disproportionately.
Efficient Schedules
Given that the shortest possible schedules are out of reach for nearly all organizations, efficient schedules or nominal
schedules are a more realistic alternative.
Assumptions—Assume that you do most things right.
1. Your team has drawn its talent from the top 25 percent of the talent pool (both analysts and developers)
2. Everyone has worked with the programming language and environment for a few years
3. Turnover is less than 6 percent per year
4. There is shared consensus about the mission
5. No significant conflicts
6. Staffed using an efficient staffing pattern
7. Efficient user of programming tools
8. Use of modern programming practices
9. Active risk management
10. Excellent physical environment
11. Integrated use of communication tools
12. Use of rapid development practices
These schedules can be compressed up to 25 percent
Nominal Schedules
Intended for use on average schedules. Most projects are average.
Assumptions
1. Your team has drawn its talent from the top 50 percent of the talent pool
2. The average team member has some familiarity with the programming language and the environment, but not
necessarily extensive familiarity
3. The team has, on average, had some experience in the application area
4. These teams might not gel
5. The team might experience some conflicts
6. They can experience turnover of from 1—12 percent per year
7. Programming tools and modern programming practices are used to some extent
8. Some of the rapid development practices might be used, but they aren’t used to their best advantage
9. Risks may be managed less actively than is ideal
10. Communications tools are readily available, but they might not be integrated into the normal workflow
11. The office environment is somewhat less that ideal, but adequate
These schedules can be compressed by up to 25 percent.
There is a 50/50 chance of completing these schedules on time.
Compressing nominal schedules can produce schedules that are of similar duration to the efficient schedules but that are
far more costly because of less efficient development practices.
Organizations reap significant benefits by using efficient development practices.
VII.
Estimate Refinement
It is possible to refine a project estimate as the project progresses, and you should do that.
The typical process that people follow is to allow themselves to be forced into making a single-point estimate early on and
then be held accountable for it.
Examples of Estimation Values over Time
Point in Project
Single-Point Estimate (not good idea)
Initial product concept
100
Approved product concept
100
Requirements specification
135
Product design specification
145
Detailed design specification
160
Final
170
Range Estimate (good idea)
25-400
50-200
90-200
120-180
145-180
170
Failure to acknowledge imprecision is a sign of a bad estimate.
Rather than losing the customer’s confidence by taking one schedule slip after another, build confidence by refusing to
provide more precision than is reasonable and by consistently meeting the customer’s expectations.
The number of times you revise an estimate can affect whether it is accepted. If you explain the estimation story ahead of
time and promise to provide increasingly refined estimates at regular milestones, which will make for an orderly,
respectable process.
A. Recalibration
When you miss a scheduled date, should you:
1. Assume you can make up the lost week later in the schedule?
2. Add the week to the total schedule?
3. Multiply the whole schedule by the magnitude of the slip?
Projects hardly ever make up lost time—they tend to get further behind.
Changing the schedule estimate after missing or beating a milestone isn’t the only option. You can change the product or
the cost. The only thing you can’t do is to keep the schedule, the specs, and the cost the same and expect the project to
improve.