Page 30 -

changing the level of detail or granularity of each feature, and by combining multiple
features into a single one. Sometimes those features are small (“screw-top cap,” “holds
one liter of liquid”); sometimes they are big (“four-wheel drive,” “seats seven passen-
gers”). It is useful to describe a product in about 10 features in the vision and scope doc-
ument, because this usually yields a level of complexity that most people reading it are
comfortable with. Adding too many features will overwhelm most readers.
Each feature should be listed in a separate paragraph or bullet point. It should be given
a name, followed by a description of the functionality that it provides. This description
does not need to be detailed; it can simply be a few sentences that give a general expla-
nation of the feature. However, if there is more information that a stakeholder or
project team member feels should be included, it is important to include that informa-
tion. For example, it is sometimes useful to include a use case (see Chapter 6), as long as
it is written in such a way that all of the stakeholders can read and understand it.
Scope of phased release (optional)
Sometimes software projects are released in phases: a version of the software with some
subset of the features is released first, and a newer, more complete version is released
later. This section describes the plan for a phased release, if that approach is to be taken.
This is useful when there is an important deadline for the software, but developing the
entire software project by that deadline would be unrealistic. The most common way to
compromise on this release date is to divide the features into two or more releases. In
that case, this section should identify specifically when those versions will be released,
and which features will be included in each version. It’s reasonable to divide one fea-
ture up between two releases, as long as it is made clear exactly how that will happen.
If a project manager needs to release a project in phases, it is critical that the project
team be consulted. Some features are much more difficult to divide than others, and the
engineers might see dependencies between features that are not clear to the stakehold-
ers and project manager. After the phased release plan is written down and agreed
upon, the project team should always be asked to re-estimate the effort and a new
project plan should be generated (see below). This will ensure that the phased release is
feasible and compatible with the organization’s priorities.

Features that will not be developed
Features are often left out of a project on purpose. When a feature is explicitly left out
of the software, it should be added to this section to tell the reader that a decision was
made to exclude it. For example, one way to handle an unrealistic deadline is by
removing one or more features from the software, in which case the removed features
should be moved into this section. The reason these features should be moved rather
than deleted from the document is that otherwise, readers might assume that they were
overlooked and bring them up in a review. This is especially important during the
review of the document because it allows everyone to agree on the exclusion of the fea-
ture (or object to it).

22 CHAPTER TWO