Page 44 -

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 mod-
erator in a Wideband Delphi session—see 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 assumption—either assume that they will buy the component, or assume that
they will build it—which 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 assump-
tion allows the team to reach a temporary decision, knowing that the final decision is still

36 CHAPTER THREE