Section 3.1. Elements of a Successful Estimate

3.1. Elements of a Successful Estimate

A sound estimate starts with a work breakdown structure (WBS). A WBS is a list of tasks that, if completed, will produce the final product. The way the work is broken down dictates how it will be done. There are many ways to decompose a project into tasks. The project can be broken down by feature, by project phase (requirements tasks, design tasks, programming tasks, QA tasks, etc.), or by some combination of the two. Ideally, the WBS should reflect the way previous projects have been developed.

A useful rule of thumb is that any project can be broken down into between 10 and 20 tasks. For large projects (for example, a space shuttle), those tasks will be very large ("Test the guidance system"); for small projects (like writing a simple calculator program), the tasks are small ("Build the arithmetic object that adds, multiplies, or divides two numbers"). The team must take care in generating the WBSif the tasks are incorrect, they can waste time going down a wrong path.

Once the WBS is created, the team must create an estimate of the effort required to perform each task. The most accurate estimates are those that rely on prior experience. Team members should review previous project results and find how long similar tasks in previous projects took to complete. Sources of delays in the past should be taken into account when making current estimates. Postmortem reports (see Chapter 8) are a good source of this information.

No estimate is guaranteed to be accurate. People get sick or leave the organization; teams run into unforeseen technical problems; the needs of the organization change. The unexpected will almost certainly happen. Therefore, the goal of estimation is not to predict the future. Instead, it is to gauge an honest, well-informed opinion of the effort required to do a task from those people in the organization who have the most applicable training and knowledge.

If two people widely disagree on how long a task will take, it's likely that the source of that disagreement is that each person made different assumptions about details of the work product or the strategy for producing it. In other words, any disagreement is generally about what is required to perform the task itself, not about the effort required to complete it. For example, given the same vision and scope document for a tool that sets the computer clock, two different developers might come up with wildly different estimates. But it might turn out that one developer assumed that the implementation would have a simple command-line interface, while the other assumed that there would be a complete user interface that had to integrate tightly with the operating system's control panel. By helping the programmers discuss these assumptions and come to a temporary resolution about their differences, the project manager can help them agree on a single estimate for the task.

A project manager can help the team create more accurate estimates by reducing the uncertainty about the project. The most effective way to do this is to do a thorough job creating a vision and scope document (see Chapter 2)the more accurate and detailed it is, the more information the team has to work with when generating their estimate. The project manager can also ensure that the team has reached a consensus on the tasks that must be performed. Finally, the project manager can lead the team in a discussion of assumptions.

3.1.1. Assumptions Make Estimates More Accurate

Once the team has agreed upon a WBS, they can begin to discuss each task so they can come up with an estimate. At the outset of the project, the team members do not have all of the information they need in order to produce estimates; nevertheless, they need to come up with numbers. To deal with incomplete information, they must make assumptions about the work to be done. By making assumptions, team members can leave placeholders for information that can be corrected later, in order to make the estimate more accurate.

For the estimates to be most effective, the assumptions must be written down. Important information is discovered during the discussion that the team will need to refer back to during the development process, and if that information is not written down, the team will have to have the discussion all over again. If an assumption turns out to be incorrect, the schedule will need to be adjusted; they will be able to point to the exact cause of the delay by showing that a documented assumption turned out to be incorrect. This will help the project manager explain any resulting schedule delay to others in the organization and avoid that source of delays in the future. The assumptions also provide a way to keep a record of team decisions, share those decisions with others, and find errors in their decisions. (The assumptions should be added to the "Assumptions" section of the vision and scope documentsee Chapter 2.)

The team should hold a brainstorming session to try to identify as many assumptions as possible. The bigger the list of assumptions, the lower the overall risk for the project. A project manager may get better results from this session by helping the team see how these assumptions can work to their benefit. Any software engineer who has had a bad experience with an estimate that has turned out to be inaccurate will appreciate the value of assumptions: they serve as a warning to the rest of the organization that the estimate is contingent on the assumptions being true. If even one of these assumptions turns out to be incorrect, the team cannot be "blamed" for the incorrect estimate that resulted.

While identifying assumptions is a skill that improves with experience, there are a set of questions that can help a novice team member figure out what assumptions he or she needs to make in order to properly estimate the software. The project manager (or a moderator in a Wideband Delphi sessionsee below) can use these questions to help lead the discussion to identify the assumptions:

• Are there project goals that are known to the team but not written in any documentation?

• Are there any concepts, terms, or definitions that need to be clarified?

• Are there standards that must be met but will be expensive to comply with?

• How will the development of this project differ from that of previous projects? Will there be new tasks added that were not performed previously?

• Are there technology and architecture decisions that have already been made?

• What changes are likely to occur elsewhere in the organization that could cause this estimate to be inaccurate?

• Are there any issues that the team is known to disagree on that will affect the project?

The last bullet point is especially important. If one team member believes that the project will go down one path while another team member believes the project will go down a different path, the estimates could vary significantly, depending on which team member is correct. For example, one team member may think that a certain off-the-shelf component should be used because that is cheaper than building it, while another team member may believe that they must build that component themselves because they cannot locate one for sale which suits their particular needs. Instead of reaching an impasse, the team can make an assumptioneither assume that they will buy the component, or assume that they will build itwhich will enable them to move forward with the estimate. It should be easier to reach an agreement at this point because it is not the final decision. By writing down the assumption, the team keeps a record of the disagreement and leaves open the possibility that this will change in the future. The written assumption will be especially useful later while doing a risk assessment for the project plan because there is a risk that the assumption is incorrect.

In other words, assumptions can help find a compromise to resolve disagreements. If two team members disagree, the team can agree to write down an assumption to temporarily resolve the issue for the purposes of the estimate. It's much easier to get people to agree on one answer temporarily by agreeing to revisit the issue later.

Discussing and writing down the assumptions in a team setting helps the team to identify potential roadblocks. For example, the team may have a genuine disagreement about whether or not to develop a user interface for their clock-setting application. The assumption allows the team to reach a temporary decision, knowing that the final decision is still open. Writing down the assumption allows the team to go back and revise the estimate later if it turns out the assumption is wrongwhich means that it is vital that everyone understands that the assumptions are allowed to be incorrect. That way, if the team estimated that they would build a command-line program but later the decision was made to go with a full user interface, everyone will be able to explain why the schedule is delayed.

Another benefit of discussing assumptions is that it brings the team together very early on in the project to make progress on important decisions that will affect development. It's all too common for a developer to make estimates after reading the vision and scope document but before ever talking to anyone about the details of the project. Even if she writes down her assumptions, she has almost certainly missed many others. A moderated discussion of assumptions gives the project team a very effective forum to discuss the unknowns of the project. Identifying unknowns eliminates the source of many inaccuracies in the estimates.

One side effect of writing down the assumptions is that it puts pressure on the senior managers to allow the project to be estimated again if any of the assumptions prove to be incorrect. This is why the project manager should plan on having the vision and scope document updated to include any new assumptions that were identified during the estimation session. This gives the stakeholders and management a chance to review those assumptions and accept or reject them very early on, before they have had a chance to interfere with the development of the software. By having the senior managers review the assumptions, a project manager can reduce a source of future project delays.

3.1.2. Distrust Can Undermine Estimates

Estimates can either be a source of trust or distrust between the project team and their managers. If the team knows that they are given the opportunity to fully justify their estimates, and that they will be allowed to reestimate if the scope of the project changes, that they won't be punished for making an honest mistake in estimation, then each team member will work very hard to produce accurate estimates. In this case, estimation can be an effective tool for team motivation. Estimates are most accurate when everyone on the project team feels that he was actively part of the estimation process. Every team member feels a personal stake in the estimates, and will work very hard to meet any schedule based on those estimates.

Estimation is, by its nature, a politically charged activity in most organizations. When a team is asked to create estimates for work, they are essentially being asked to define their own schedule. Stakeholders need the project completed but usually do not have software engineering experience, so they may not be equipped to understand why a project will take, say, six months instead of three. For this reason, project managers must take care to make the estimation process as open and honest as possible so that the stakeholders can understand what's going on.

It is common for nontechnical people to assume that programmers pad their estimates. They often have a "rule" by which they cut off a third or half of any estimate that they hear, and expect that to be the "real" deadline. They often feel, fairly or not, that the engineering team is "putting one over" on them, mostly because the entire engineering process is, to them, a mystery. This lack of trust causes engineers to automatically pad their estimates, because they know they won't be given enough time otherwise. And even when the situation is not this bad (although it often is), some environment of distrust still exists to a lesser extent in many organizations.

In many of these organizations, there are some kinds of estimatesespecially those for quality and requirements tasksthat are particularly likely to not be taken seriously. Senior managers are often willing to take the programmers' estimates at face value, even when those estimates are clearly padded. This is because, to them, programming is opaque: managers and stakeholders don't understand how code is written, so they assume that all programming tasks are difficult. They are more likely to trust programmers' estimates, even when those estimates are highly padded. Requirements analysts, on the other hand, often produce specifications using nothing more than a word processor (and many elicitation sessionssee Chapter 6). A manager or stakeholder is much more likely to trivialize that work and distrust the estimate because he (incorrectly) feels that he has an intuitive grasp on the work being done. Even worse, in some organizations there is a "rule" that testing should always take exactly one-third (or some other fixed ratio) of the programming time, which causes the testing effort to be shortchanged by only allowing exactly that much time for it instead of the actual amount of time testing would require.

Distrust in a software organization can be a serious, endemic problem. It starts with a kernel of distrust between management and the engineering team; the distrust grows until management simply won't accept the team's estimates. For example, a senior manager may decide that the team plans to spend too much time testing the software, even though the team reached consensus and all team members stand behind the estimates. A project manager must be especially careful to explain this and support that consensus when senior managers start to pick apart the team's estimates. If deadlines are handed down that do not allow enough time for the team to complete the work, it can lead to serious morale problemsand the project manager will be blamed for the delay, often by the same people who caused it in the first place.

An important part of running successful software projects is reaching a common understanding between the engineers, managers, and stakeholders. One way to do that is with a consistent set of practices. This allows the engineers' work to be transparent to the rest of the organization. Similarly, the managers' and stakeholders' needs and expectations must be transparent to the engineers. By having key managers attend the estimation session, a project manager can show them that the estimates are made systematically, using an orderly and sensible process, and that they are not just made up on a whim. When the team is having trouble reaching convergence on a task, team members should bring up examples of past results for tasks of similar size and complexity. This transparency helps everyone present (especially the observers) understand why these estimates come out as they do.