Page 50 -
P. 50
often do not understand the engineering process and what goes into building the software.
Including observers is an effective way to encourage mutual trust between the team and the
nontechnical people in the organization. While the observers do not directly contribute to
the numerical estimates, encouraging their involvement in the meetings will increase their
feeling of ownership of the final estimates that are generated by the team. When the non-
engineers participate in the discussion of assumptions and see how the team arrives at esti-
mates, they walk away with a much greater understanding of how the engineers do their
work. What’s more, the assumptions are almost always discussed on a level that can gener-
ally be understood by most of the nontechnical observers. Since these assumptions usually
end up focused on the most problematic areas of development, the observers leave the
meetings with a much clearer picture of exactly how the software will be developed.
Kickoff meeting
The goal of the kickoff meeting is to prepare the team for the estimation session. When the
kickoff meeting is scheduled, each team member is given the vision and scope document
and any other documentation that will help her understand the project she is estimating.
The team members should read all of the material before attending the meeting.
In addition, a goal statement for the estimation session should be agreed upon by the project
manager and the moderator and distributed to the team before the session. This statement
should be no more than a few sentences that describe the scope of the work that is to be esti-
mated (“Generate estimates for programming and testing the first phase of Project X”).
The moderator leads the meeting, which consists of the following activities:
• The moderator explains the Wideband Delphi method to any new estimators.
• If any team member has not yet read the vision and scope document and supporting
documentation, the moderator reviews it with the team. (If this happens, the meeting
should be expected to take an extra half-hour to hour.)
• The moderator reviews the goal of the estimation session with the team, and checks
that each team member is sufficiently knowledgeable to contribute.
• The team discusses the product being developed and brainstorms any assumptions.
• The team generates a task list consisting of 10–20 major tasks. These tasks represent the
top level of the work breakdown structure—additional detail can be generated later
and/or discussed in the assumptions. This high-level task list is the basis for the esti-
mates that are going to be created.
• The team agrees on the units of estimation (days, weeks, pages, etc.).
The team must agree on the goal of the project estimation session before proceeding with
the rest of the estimation process. In most cases, the goal is straightforward; however, it is
possible that the team members will disagree on it. Disagreement could focus on missing
requirements, on which programs or tasks are to be included, on whether or not to estimate
user documentation or support requirements, on the size of the user base being supported,
or other basic scope issues.
42 CHAPTER THREE