The FDD Process: Feature-Driven Development's Five Processes, Step by Step

This guide walks through Feature-Driven Development’s five processes the way you’d run them on a real project: who does what, what each process produces, how long it should take, and how to track progress once features are flowing. It assumes you’ve already decided FDD suits your situation. If you haven’t, read Feature-Driven Development explained first; it covers where FDD came from, why it suits large teams in a stable domain, and when not to use it.

One scenario runs through every step. A freight logistics company is replacing the system its customers use to book, track and pay for shipments. The domain is well understood: the business has quoted, booked and invoiced freight the same way for years. There are 24 developers, four of them senior enough to lead. The old system is a tangle of database tables that nobody fully understands, and the new one has to make sense to everyone who works on it.

Who this is for

• Delivery leads and architects starting a large build on a stable, well-understood domain.
• Senior developers about to take on a chief programmer role.
• Teams already “doing FDD” whose feature list has turned into a flat backlog with a different name.

Before you start

• A domain that won’t change under you. FDD front-loads modeling. If you’re still discovering what users need, that effort is wasted.
• Domain experts with time. The first process needs people who know the business sitting with developers for several days.
• Senior developers who can lead. You need a chief architect for the model and one chief programmer for roughly every six to eight developers.

Step 1: Name the roles before anything else

FDD’s processes assume specific people. Name them first:

• Chief architect: owns the overall model and facilitates the modeling sessions.
• Chief programmers: each owns a set of features and leads the small teams that build them.
• Class owners: each developer owns specific classes (or modules) and makes the changes to them.
• Domain experts: the business people who explain how the work actually happens.
• Development manager and project manager: keep the teams staffed, the work flowing and the progress reports honest.

In the scenario: the most experienced developer becomes chief architect. The other three senior developers become chief programmers, each leading a group of six or seven. Two operations managers and a billing lead are the domain experts.

Step 2: Develop an overall model (process 1)

Get the domain experts and developers into the same room. For each area of the business, a domain expert gives a short walkthrough: what happens, in what order, and which rules matter. Small groups of three or four then sketch a model of that area: the main things in the domain, how they relate and what each is responsible for. The groups compare sketches and the chief architect merges the best parts into one model.

Keep it to the shape of the domain, not the detail of every field. This is the process teams most often overdo: days to a couple of weeks is right for most systems, not months.

In the scenario: six walkthroughs over eight working days cover quoting, booking, carriers, tracking, invoicing and claims. The merged model has about 40 classes. It shows, for the first time, that “shipment” and “consignment” meant different things in different teams. That one finding justifies the eight days.

Step 3: Build the features list (process 2)

Break the model down into features using FDD’s three levels:

1. Subject areas: the big parts of the business (Booking, Billing).
2. Feature sets: the business activities inside each area (Quoting a shipment).
3. Features: small functions the client cares about, written as action, result, object: “Calculate the freight charge for a shipment.”

Any feature that would take more than two weeks gets split. Most should take a few days. Features describe what the business sees, never technical work: “Create the shipments table” is not a feature.

In the scenario: the list has 6 subject areas, 22 feature sets and 214 features. “Handle international shipments” is far too big. It becomes its own feature set, International shipments, with features such as “Generate the customs declaration for a shipment”, “Calculate the import duties for a shipment” and “Record a border hold on a shipment”.

Step 4: Plan by feature (process 3)

The project manager, development manager and chief programmers sequence the feature sets, taking into account dependencies, business priority and how evenly the work spreads across the teams. Then:

• Each feature set is assigned to a chief programmer.
• Each class from the model is assigned to a class owner.
• Each feature set gets a target month for completion.

The output is a plan of feature sets with owners and dates, not a schedule of every feature.

In the scenario: the Booking feature sets come first, quoting then booking, because billing depends on them. Each chief programmer leads one subject area at a time. The International shipments feature set comes last, because a customs regulation change is due next year and the business wants to wait for it.

Step 5: Design by feature (process 4)

Each chief programmer picks a small batch of features from their set, enough for about two weeks. They form a feature team from the owners of the classes those features touch, so teams change from batch to batch. For each batch, the feature team:

1. Gets a domain walkthrough if the feature needs one.
2. Sketches how the classes will work together for each feature.
3. Updates the model where the design changes it.
4. Holds a design inspection: the team and chief programmer review the design before any code is written.

In the scenario: Priya’s first batch, calculating the freight charge and applying the fuel surcharge, touches Shipment, Rate Card and Surcharge. Their three owners form the feature team for two weeks. The design inspection finds that fuel surcharges change weekly, so rates must be dated. That’s cheap to fix on a whiteboard and expensive to fix after release.

Step 6: Build by feature (process 5)

Each class owner writes the code for their classes. The feature team holds a code inspection, the class owners unit test their changes, and the chief programmer promotes finished features to the main build. A feature is done only when it’s in the build.

Run the build continuously and automate the tests. FDD predates most modern CI tools, but nothing in it conflicts with them.

In the scenario: the first batch is two features: calculate the freight charge and apply the fuel surcharge. After nine working days the freight charge is promoted. The fuel surcharge fails code inspection because its rounding rules don’t match the billing lead’s spreadsheet. The billing lead joins the re-inspection the next morning to settle it.

Step 7: Track progress by milestone

FDD tracks each feature through six milestones, each worth a fixed share of the feature:

Milestone	Weight
Domain walkthrough	1%
Design	40%
Design inspection	3%
Code	45%
Code inspection	10%
Promote to build	1%

A feature’s progress is the sum of the milestones it has passed. A feature set’s progress is the average across its features. Report feature sets on a “parking lot” chart: one box per feature set showing its percent complete and target month, colour-coded as in progress, needs attention, late or complete.

In the scenario: at the end of month two, Quoting a shipment is 55% complete and in progress, and Assigning a carrier is 20% complete and needs attention. The parking lot shows the delay on one page, without anyone writing a status report.

Step 8: Add the feedback loops FDD leaves out

FDD prescribes no regular review with stakeholders and no retrospective. Add both:

• Demo every completed feature set to the domain experts, on the build, not on slides.
• Hold a retrospective every two to four weeks with the chief programmers and a few class owners.

In the scenario: the first Quoting demo shows that customer service agents quote over the phone and need a faster screen than customers do. That becomes three new features in the Quoting set, added before the agents’ launch rather than after.

Copy-paste templates

Features list

Subject area: ____________
Feature set: _____________
Chief programmer: ________
Target month: ____________

Features (estimated days)
[ ] <action> the <result>
    <by|for|of|to> a(n) <object>
    (__)

Example
Subject area: Booking
Feature set: Quoting a shipment
Chief programmer: Priya
Target month: March

[ ] Calculate the freight charge
    for a shipment (4)
[ ] Apply the fuel surcharge
    to a quote (2)
[ ] Validate the delivery
    postcode of a shipment (1)
[ ] Save the quote for a
    customer (2)
[ ] Convert the quote to a
    booking (3)

Rules
- Split any feature over
  10 days.
- No technical tasks as
  features.

Plan by feature

| Feature set           | Subject area | Chief programmer | Depends on        | Target month |
|-----------------------|--------------|------------------|-------------------|--------------|
| Quoting a shipment    | Booking      | Priya            | -                 | March        |
| Booking a shipment    | Booking      | Priya            | Quoting           | April        |
| Assigning a carrier   | Carriers     | Daniel           | Booking           | April        |
| Invoicing a customer  | Billing      | Mei              | Booking           | May          |
| Handling a claim      | Claims       | Mei              | Invoicing         | June         |

Milestone tracker (one feature set)

Feature set: Quoting a shipment
W = walkthrough 1%, D = design 40%
DI = design inspection 3%
C = code 45%
CI = code inspection 10%
B = promote to build 1%

| Feature          | W  | D  | DI| C  | CI | B | Done |
|------------------|----|----|---|----|----|---|------|
| Freight charge   | x  | x  | x | x  | x  | x | 100% |
| Fuel surcharge   | x  | x  | x | x  |    |   |  89% |
| Postcode check   | x  | x  | x |    |    |   |  44% |
| Save the quote   | x  | x  |   |    |    |   |  41% |
| Quote to booking |    |    |   |    |    |   |   0% |

Feature set progress
= (100+89+44+41+0) / 5
= 55%

Design inspection checklist

[ ] Every feature in the batch
    is covered by the design
[ ] The design matches the
    overall model, or the model
    has been updated
[ ] Every class touched has its
    owner in the feature team
[ ] Business rules were checked
    with a domain expert
[ ] Anything that changes over
    time (rates, rules, prices)
    is handled
[ ] Each feature can be built
    and promoted within two weeks

Common mistakes

Modeling for months. The overall model becomes a big upfront design phase. Fix: keep it to the shape of the domain; detail is added feature by feature in process 4.

Features that are really tasks. “Build the rates API” appears on the list. Fix: write every feature as action, result, object, in terms the business would recognise.

Features too big to finish. A feature stays at 44% for a month. Fix: split anything over two weeks before it’s planned.

The chief programmer as bottleneck. Every design and every promotion waits for one person. Fix: keep chief programmers to six to eight developers each, and let experienced class owners run inspections.

Skipping inspections. Teams move from design straight to code, or promote code nobody has inspected, so the percentages climb and the build doesn’t improve. Fix: no coding starts until the design inspection is done, and nothing is promoted until the code inspection is done.

No feedback from the business. Features are built to the model, but nobody sees them until release. Fix: demo every completed feature set to the domain experts.

You’re done when

• The chief architect, chief programmers, class owners and domain experts are named
• An overall model exists, built with domain experts in days or weeks, not months
• The features list has subject areas, feature sets and features in action-result-object form
• No feature is bigger than two weeks
• Every feature set has a chief programmer and a target month, and every class has an owner
• Each batch has a design inspection before coding and a code inspection before promotion
• Progress is reported by milestone on a parking lot chart
• Completed feature sets are demonstrated to the domain experts