Feature Driven development(FDD) is a little different from Scrum and eXtreme Programming. Reflecting its use perhaps on larger projects, FDD defines a three level hierarchy for its agile requirements that it calls features.
Continued from Burn down charts...
Feature Driven development (FDD) is a little different from Scrum and eXtreme Programming. Reflecting its use perhaps on larger projects, FDD defines a three level hierarchy for its agile requirements that it calls features.
While it might be tempting to use the fact that StarTeam requirements can have child requirements, it is probably safer to stick with folders to organise the feature list into the hierarchy of feature areas, feature sets. This is because feature areas and feature sets are treated more as containers of requirements than requirements in their own right, even though each one could probably be expressed as a high-level requirement.
Typically during the process of software development, when a Chief Programmer is starting an iteration through Design by Feature and Build by Feature activities, they will create a Work Package. Essentially this starts as the small group of features that he and his newly formed feature team will design and build (code, test, and inspect but not necessarily in that order) next
To achieve this in StarTeam, the Chief Programmer creates a new folder for their work package and then hold down the Control key as they drag features (requirements) from the feature set folders into the new Work Package. Each time they do this, StarTeam asks if they want to Share Itemto which they respond Yes.
The result of this is that the feature now effectively exists in both folders. Modification made to the feature in one folder are reflected in the other folder.
As the feature team proceed through the iteration, artifacts like notes from the domain walkthrough, sequence diagrams, modified source code files, and design and code inspection results, can be attached or linked to the relevant feature in the work package.
FDD does not mandate any particular reporting style. However, three or four charts and reports are commonly produced on a regular basis during a project:
The feature wall chart: As feature teams proceed through a
design by feature/build by feature iteration they record when six
different milestones are met and compare those against dates that
the chief programmer estimated for those milestones. On a regular
basis the full list of features is updated showing planned and
actual dates for these milestones. By convention, features that
have not been started are left with white backgrounds, completed
features are colored green, those in progress are colored yellow
except for those that are blocked or delayed for some reason which
are shown in red. This report is typically displayed on an
accessible wall in or near the project team’s area.
A summary report of the number of features in each set that are not started, in progress, delayed, or completed is produced on a regular basis for team leads.
A burn up chart is produced to show features completed against time.
Lastly a ‘parking lot’ chart is produced for the project leadership and senior management graphically showing each feature set in it’s feature area, with number of features, percentage complete and status.
As with Scrum and eXtreme Programming, the easiest way to create these charts and reports is to export the feature data into a spreadsheet like Microsoft Excel and use the reporting and charting mechanisms there.