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.
Establish Network Arrangement
Establish Equipment
features...
Establish Network Element
features...
Establish Node
features...
Establish Site
features...
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.
Establish Network Arrangement
Establish Equipment
features...
Establish Network Element
features...
Establish Node
features...
Establish Site
features...
New Features
features...
Of course, New Features business activities are added to whatever subject areas have new work.
© Nebulon Pty. Ltd.
With thanks to the review team: Phil Bradley, Gavin Baker.
