Feature Driven Development
While most Agile methodologies start with a handful of principles or a specific set of processes, the center of Feature Driven Development (FDD) is the domain model. Creating a model of the domain is the foundational step for FDD, which requires collecting domain knowledge from all domain experts (sometimes called Subject Matter Experts or SMEs), and integrating this knowledge into a unified model (or set of models) representing the problem domain. Once this model and any other requirements have been evaluated, a rough plan is drawn up to determine what resources will be needed to build the masterpiece. A small set of features are identified for a team to work on for a period of time recommended to last no more than two weeks. Once the initial set of features is delivered, another set is tackled. Multiple teams can work in parallel on different sets of features, with all activity being tracked on a per feature basis.

The basic unit of work in FDD is a feature, which is defined as a small, client-valued function expressed in the form:

<action><result>[of|to|for|from]<object>.

This expression can be restated as: an action, causes a result, to an object. The section in the brackets is optional to make the feature easier to read. An example of a feature is: Calculate the monthly interest rate for an adjustable rate mortgage. Here "calculate" is the <action>, "monthly interest rate" is the <result>, and "an adjustable rate mortgage" is the object participating in this feature.

Features can be combined into Feature Sets, and Feature Sets can be aggregated into Subject Areas. Requirements are usually gathered in a top down approach, defining all the Subject Areas for the system, breaking these down into Feature Sets, and eventually down into Features, from which tasks can actually be defined and estimated. Feature Sets typically reflect a business activity, and Subject Areas commonly correspond to general business practices. Some possible Feature Sets are "Making a Deposit," "Making a Withdrawal," "Viewing an Account Balance," all of which may be part of the "Managing an Account" Subject Area.

FDD specifies five specific processes that are to be followed, in this specific order:

1. Develop an Overall Model
2. Build a List of Features
3. Plan by Feature
4. Design by Feature
5. Build by Feature

Again, it is important to understand that absolutely everything is planned, built, managed, and tracked on a per-feature basis. Other units such as feature sets and subject areas are available for higher level planning and reporting, but the key universal unit is the feature.

FDD relies on specific roles and responsibilities more than almost any other Agile methodology. FDD also tends to move away from shared ownership of code and artifacts that other Agile methods promote, and the team roles reflect this. The nine roles defined for FDD are:

1. Project Manager—Responsible for all administrative aspects of the project, including the financial and reporting ones.
2. Chief Architect—Responsible for the overall design of the system, including running all design sessions, code reviews, and technology decisions.
3. Development Manager—On the hook for the daily development activities. Coordinating the development team and their activities, and dealing with resource issues.
4. Chief Programmer—A senior developer involved in ongoing design and development activities, and is assigned to be responsible for one or more Feature Sets.
5. Class Owner—A developer who works under the direction of a Chief Programmer to design, code, test, and document features as they are implemented.
6. Domain Expert—Any business related stakeholder who can define required features that the system should provide. These would include clients, users, and various analysts; anyone who has knowledge of how the business works that could impact the system.
7. Tester—Responsible for verifying that each feature performs as defined.
8. Deployer—Deals with not only the actual deployment of code to various environments, but also the definition and/or conversion of data from one format to another.
9. Technical Writer—Responsible for creating and maintaining all the online and printed documentation that a user will need for the final system.

FDD uses several unique and specific mechanisms to report project activity and progress. The least unique of these is the feature list and the task list. Many Agile methodologies use some sort of list to track requirements and work done on requirements. In FDD, these lists all correspond to a specific feature.

Figure 3. Feature Set Progress Report. The Feature Set Progress Report illustrates progress of feature development in each subject area. Light green Feature Sets are in progress and on schedule, dark green Feature Sets are completed, and grey Feature Sets are behind schedule.

Capturing exactly where a feature is in its development cycle is done using a table that tracks six specific milestones:

1. Domain Walkthough
2. Design
3. Design Inspection
4. Code
5. Code Inspection
6. Promote to Build

These milestones are tracked by the date each is completed and by the Chief Programmer responsible for that specific feature.

Feature milestones are rolled up into a table showing feature sets. This allows project stakeholders to see how the project is progressing. Things can be rolled up into subject areas as well if there is value in doing so. Completed features are also tracked across the entire project using a line graph. This graph shows the cumulative total by day or week of all features that have been completed.

The final group of reports is the Feature Set Progress Report, which is very unique to FDD (see Figure 3). This report is color coded and shows each Feature Set in the project, what percent complete it is, how many features are in each area, the name of the Chief Programmer for each Feature Set, and the month and year when each is targeted to be completed.

Three More to Go
We couldn't cover all the Agile methodologies in one article. In fact, we can't cover all the Agile methodologies in two articles either but we hit all the big ones. In the next article we continue this exploration by analyzing the Agile Unified Process, Crystal, and DSDM. And we bring all this data together with a great summary of all the different approaches and look at the contexts in which each methodology excels. Finally, we offer tips when choosing a methodology or combination of methodologies for your project.