Most agile methods were written for a team that fits in one room, and most of the arguments about scaling them are arguments about what to add when it doesn't. FDD came from the other direction: it was built on a project with dozens of developers and asked how little process would still let them work from one model. FDD is the rare agile method where the architecture is decided before the first feature is built, which is why it keeps resurfacing wherever a large team is tired of rediscovering its own design one story at a time.
In this glossary topic:
What is Feature Driven Development (FDD)?
Feature Driven Development (FDD) is an iterative and incremental software development method that organizes a project around small, client-valued pieces of function called features, building and delivering them one at a time on top of an object model of the whole domain. Jeff De Luca created it in 1997 to run a large banking project in Singapore, with Peter Coad contributing the modeling approach, and it was first written up in 1999 as a chapter of Coad's book Java Modeling in Color with UML. Stephen Palmer and John Felsing's 2002 book A Practical Guide to Feature-Driven Development gave it its full description.
FDD belongs to the family of agile methodologies, and it was among the methods represented when the Agile Manifesto was written in 2001. It differs from most of its relatives in two ways: it models the domain before any feature is built, and it was designed for teams of dozens of developers rather than for a single room. FDD is the agile method that kept the architecture up front and made the feature, not the sprint, the unit of progress.
How does FDD work?
FDD runs as five processes. The first three happen once, at the start of the project, and the last two repeat for every feature until the list is empty.
- Develop an overall model: domain experts and developers walk through the business domain together and sketch a class model of its shape, detailed enough to hang features on but not to design them.
- Build a feature list: the team breaks the domain into business activities, each activity into feature sets, and each set into features, producing an inventory of everything the system has to do.
- Plan by feature: the project manager, development manager, and chief programmers order the feature sets, set completion dates, and assign each class to an owner.
- Design by feature: a chief programmer picks a small batch of features, forms a feature team from the owners of the classes involved, and the team produces sequence diagrams and class designs, then inspects them.
- Build by feature: the class owners write the code, the team inspects it, unit tests run, and the finished classes are promoted to the regular build.
Design and build alternate in short passes of days to two weeks. Nothing in FDD counts as finished until it is in the build, which keeps progress measured in working features rather than in tasks ticked off.
What counts as a feature in FDD?
A feature in FDD is a small piece of client-valued function, named with a fixed template: an action, a result, and an object, in the form "[action] the [result] [by, for, of, or to] a(n) [object]." "Calculate the total of a sale" and "Validate the password of a user" fit. "Set up the database" does not, because no client would recognize it as something the system does for them.
The template is paired with a size rule. A feature should take a feature team no more than two weeks to deliver, and most take far less; anything larger is split until it fits. Features group into feature sets, which correspond to business activities such as making a sale, and feature sets group into major feature sets, or subject areas. The feature list is the project's scope, its plan, and its progress report at once, which is why FDD spends an entire process producing it before any code is written. The resemblance to user stories is real but partial: both are small, client-facing, and kept in a list, but a feature is tied to the domain model and sized by the template rather than negotiated with a product owner.
What roles does FDD define?
FDD names six key roles. The project manager owns the schedule and the budget; the chief architect owns the overall model; the development manager runs day-to-day development; chief programmers lead feature teams; class owners write and maintain the classes assigned to them; and domain experts, the users, clients, and analysts who know the business, supply the knowledge the model and the feature list depend on. Supporting roles such as release manager, build engineer, and technical writer fill in around them.
Two of these set FDD apart from other agile methods. Class ownership is individual: one developer is responsible for each class, as opposed to the collective code ownership Extreme Programming prescribes, on the argument that an owner knows the class well enough to change it safely. Feature teams are temporary: a chief programmer assembles one for each batch of features from whichever class owners that batch touches, so a developer may sit on several feature teams at once. Ownership is fixed to the code and teams are fixed to the work, and the chief programmer is the hinge between the two.
How does FDD differ from Scrum?
Scrum organizes time. Work is cut into sprints of a month or less, each with its planning, daily scrum, review, and retrospective, and a product owner reorders the backlog at every boundary. Scrum says nothing about architecture, modeling, or who owns which part of the code. FDD organizes the work itself: the unit is the feature, the plan is the feature list, and the sequence is set by chief programmers against the domain model. There are no sprints, and the only fixed rhythm is the regular build.
The other difference is up-front investment. Scrum expects the design to emerge sprint by sprint; FDD builds an overall model first so that a large team can work in parallel without rediscovering the architecture story by story, the coordination problem the Scaled Agile Framework answers by adding layers above the teams. Scrum trades up-front certainty for adaptability, and FDD trades some adaptability for a model that dozens of developers can build against. The Agile Practices lesson sets the main frameworks side by side for a team choosing among them.
What does FDD look like in practice?
FDD's shape is easiest to see drawn as its five processes in order: develop an overall model, build a feature list, plan by feature, then design by feature and build by feature. The first three run once and produce the model, the list, and the plan; the last two repeat for every feature until the list is empty. The loop is where the project spends almost all of its life, and the three steps before it exist so that every pass starts from the same model and the same ordered list.
The five FDD processes drawn as one ring: the model, the feature list, and the plan are produced once at the start, and design by feature and build by feature repeat for every feature until the list is done. From the lesson Advanced Processes & Frameworks in Product Management.
Why does FDD matter for designers and product managers?
FDD is an engineering method. "Design by feature" means sequence diagrams and class designs, not screens, and nothing in the five processes says how a feature's interface gets decided or tested with users. A designer joining an FDD project will find no slot labeled for them, and the risk is that interface work gets squeezed into the build pass as an afterthought.
What FDD does offer design is an early door. The domain walkthrough and the feature list are where the product's vocabulary and scope get fixed, and a designer in those sessions shapes every feature that follows. The feature template is also a useful discipline on its own: a feature that cannot be named as an action, a result, and an object for a client is usually a feature nobody asked for. FDD decides when a feature is done; it leaves whether the feature was the right one, and how it should look, to the people around it.
For product managers, the feature list reads like a product roadmap at the finest grain, with progress reported per feature set rather than as points burned down. The vocabulary can mislead, though: FDD's "feature" is a unit of engineering work, not the capability a roadmap promises. The Development Methodologies lesson walks product managers through the choice among delivery methods that FDD sits within.
