Issue 6 - How To Record New Features

Mon, 10/06/2003 - 13:55 — Jeff De Luca

De Luca on FDD Newsletter Issue 6

How To Record New Features

As a
project progresses, new knowledge is acquired from various sources
and new features are created for the work that must be done as a
result of this new knowledge. Feature Driven Development is designed
to cope with new knowledge and has mechanisms to adapt.

During a
project, additional features can be identified and added to the
features list and this is of course quite common. When this happens,
I create a new business activity called "New Features" for
that subject area and this is where the new features live. I don't
expose them as a parking lot in the parking lot chart until the
number of new features exceeds 10% of the original number of
features. This is an old Ed. Yourdon rule that I've used for many
years. That is, if any project dimension (e.g. scope, resources,
time, etc.) gets off by more than 10% then you can't recover without
something else giving by 10%. This has worked well for me in practice
over a lot of years and it is incorporated into this part of Feature
Driven Development. So, when the number of new features exceeds 10%
it is at that point that they are exposed to top management.

Remember that we
have been reporting to top management using the parking lot chart for
some time now and they are very familiar with it. They also
understand the reporting well because every part of it is expressed
in client-valued terms. I can tell you from experience that this is a
great position to be in as a project manager. When I go to such a
steering committee meeting I state that in the next reporting period
% complete may drop and this is why. I can show them the exact list
of new features against the current (remember every feature is
expressed in client-valued terms) and when I do so the person in
charge never looks at me - he/she looks straight at the users. It's a
very simple equation. Something has to give - either the scope is cut
(i.e. features are removed) or the schedule is adjusted. You
demonstrate great control as a project manager here as you have the
quantitative and qualitative data behind you that the client is
already used to and comfortable with.

The fine
granularity of FDD features makes dealing with scope creep easier.
Feature Driven Development is no silver bullet for scope creep, but
the feature list being expressed in client-valued terms plus the fact
that the features are so fine-grained means there is very little
wiggle room for a user to claim some significant additional function
that was "always supposed to be performed" as a part of any
particular feature.

The "New
Features" business activities also include changed features. For
example, if a number of features are already finished but they have
to be redone because of a requirements change, then a number of new
features are created that represent this work (rework) and those
features are placed in the New Features business activity for their
respective subject areas.

A Simple
Example:

Part of the
features list for a telecommunications project may have looked like
this.

As the project
progresses we acquire new knowledge from various sources and we
create new features for the work that must be done as a result of
this new knowledge. The work is wholly contained within the Establish
Network Arrangement subject area. Therefore, a business activity
called New Features is added to the Establish Network Arrangement
subject area to hold the features that represent this new work.