FDD is documented as five processes, each described on no more than one double-sided letter-sized piece of paper.

Feature-Driven Development is documented as five processes, each described on no more than one double-sided letter-sized (A4/B4) piece of paper. Jeff De Luca publishes the latest versions of the processes on his website.

The latest FDD process descriptions from Nebulon...

The five processes consist of three initial, project-wide activities that create an initial overall model, an initial, overall list of client-valued functional requirements (features), and an initial overall development plan. This is followed by two related design and build activities that are repeated together. Each iteration of these two activities takes one or a small number of related features through an analysis, design, build and verify cycle.

FDD Process #1 FDD Process #2 FDD Process #3 FDD Process #4 FDD Process #5 FDD processes

FDD Process Versions

Jeff De Luca wrote the original versions of the FDD process descriptions in Singapore at the end of 1997.

Peter Coad modified the process descriptions for publication in the Java Modeling in Color with UML (JMCU) book in 1999, tailoring them to fit more closely with the 'modeling in color' technique promoted by the rest of that book. They were also written in a more active form of language than the originals.

The more active language was an improvement, in my opinion. The tying of the processes so closely to the modelling in colour technique, however, was unnecessary and overemphasis of a couple of items in processes 1 and 2 caused some confusion. The JMCU versions can be found in chapter 6 of that book.

FDD and 'modeling in color' are really independent of each other. They just happen to complement each other amazingly well. Jeff De Luca has published an updated set of process descriptions on his Nebulon website that decouple the processes again from the 'modeling in color' technique and returned to some of the more business-system oriented terms used in the Singapore originals.

In the end, for the version of the processes included in A Practical Guide To Feature-Driven Development, I chose to start from the originals but borrow improvements (in my personal opinion) in language style and terms from both the JMCU book and the latest Nebulon versions. The result is closer to the Nebulon versions than the JMCU versions but is written in the active language of the JMCU versions, uses some of the more generic terms of the JMCU versions, and with the help of a thorough review by a professional copy editor, tidies up the grammar, vocabulary, and use of capitalization. Having an American publisher, I was forced to use American spelling variations instead of those used throughout the rest of the world.

The hardest thing to decide was what to call feature sets and feature areas. I dislike the major feature set of the JMCU book because, to me, the use of the major term implies that the feature set is more important than others. In my opinion, the major term does not convey well the idea that a major feature set contains smaller feature sets.

The original version and the latest Nebulon versions use of the terms 'subject area' and 'business activity' instead and, as Jeff is the original author, these are the official FDD terms. However, at the time of writing  A Practical Guide... I was unhappy with these terms because I had applied FDD on projects that were not building business systems. Also, the use of the term activity conflicted with the use of that term in UML 1.x at the time. This second objection is not so strong now with the redefinition of that term in UML 2.x to be a container of actions but my first objection still remains.

In the end, I settled for feature areas containingfeature sets containing features in A Practical Guide.... Suggestions for better names are always welcome but 'use case' is not one of them as Mac and I discuss in one of our not-quite-OSCAR-winning bits of dialogue in A Practical Guide...

Chapter four of A Practical Guide ... includes a version of the five process descriptions. It also explains the scope covered by the FDD processes, the reason why the descriptions are so concise, and the format used for the descriptions. The processes as they appeared in the book are:

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

FDD Process Description Format

Although the exact task breakdown, the precise wording, and some of the terms differ between the four versions mentioned above, the actual content is far more similar than it is different. The differences might be compared to various mainstream English translations of the bible. Although scholars may argue over the exact words used in each, the message remains the same.

All four versions of the processes mentioned above also use the Entry-Tasks-Verification-Exit (ETVX) sections suggested by M. A. Rajashima and the layout and shading inspired by Edward Tufte's book Envisioning Information.

Each process description starts with two or three sentences giving an overview of the activity. This is followed by an entry criteria section that lists the conditions that must be true before the activity can start (preconditions). The main part of the description consists of a list of tasks such as the one below:

Develop a Team Model Modelling Team Required
A member from each small group presents that group's proposed model for the domain area. The Chief Architect may also propose further model alternatives...

The shaded area names the task, indicates who is involved in performing the task and whether the task is mandatory or not. This is followed by a short explanation of what is required to be done for that task.

The list of tasks for the activity are followed by a explanation of the results of the task are verified (checks on the quality of the results) and this if followed by a set of exit criteria that must be met before the activity is considered finished (checks on the recording of the results).

Concise Descriptions

The FDD processes can be described so concisely because:
  • teams generally do not have time and inclination to read and digest large process documents full of rules, tasks, and guidelines
  • more detail would have significantly diminishing returns
  • there needs to be enough room to adapt and innovate within the process
  • feature teams under the guidance of the Chief Programmers are expected to sort out the tiny details of applying the process on a day to day basis
  • the processes do not try to address every activity in the project.


The FDD processes only cover the core analysis, design and coding activities in a software development project. There are numerous other surrounding activities that still need to be done but all of these are irrelevant if the team cannot actually produce working software that meets the clients needs. Some of these activities are addressed briefly in later chapters of A Practical Guide... with emphasis on process improvements that can be made when an agile process like FDD is being used.

The fact that FDD does not cover the whole spectrum of software development project activities also means that it can be used in between established initial requirements elicitation and system testing activities within an organisation. This makes FDD easier to adopt in organisations where business analysts and system test live in different departments to the developers.

Follow me on Twitter...