Feature-Driven Development (FDD): The Agile Method Explained

Feature-Driven Development (FDD) is an agile methodology that builds a project around a shared domain model first, then delivers small, client-valued pieces of function called features on a short, repeatable cycle. Where Scrum organizes work around sprints and a self-managing team, FDD organizes work around the software's object model and a fixed set of named roles, which is why large, domain-heavy teams tend to reach for it instead.

That difference isn't academic. Scrum's light process leans on the team to sort out design and technical direction as it goes. On a 50-person, multi-team project, that can turn into five different interpretations of the same domain object. FDD front-loads exactly the modeling work that keeps everyone building against the same picture.

Key Facts

• Jeff De Luca created FDD in 1997 to run a 15-month, 50-person banking project in Singapore known as PowerLender, as documented by IT Project Services.
• FDD organizes work into five processes: two run once for the whole project, three repeat for every feature. The structure is visible in the chapter list of the method's canonical book (Pearson) and summarized here.
• Each feature moves through six milestones weighted from 1% to 45%, so a feature is already 44% complete before a single line of code is written.
• A feature is capped at about two weeks of work and named with a fixed action-result-object template, such as "Calculate the total number of people."
• FDD's Parking Lot chart rolls feature-level percentages up to the subject-area level, the reporting tool the method is still known for.

What Problem Feature-Driven Development Solves

Most agile methods assume a small, co-located team that can hold the whole system in its head. FDD assumes the opposite: a team big enough that no single person can. It was built for exactly that setting, a large, distributed development effort with a real domain (banking, insurance, logistics) sitting underneath the code.

Scrum's answer to scale is more Scrums: split the team into multiple Scrum teams, coordinate through a Scrum of Scrums, and trust each team to interpret the shared backlog consistently. That works, but it depends on strong communication discipline across teams that are, by design, self-organizing and loosely coupled. Extreme Programming solves a different problem again: it doesn't touch team structure at all, it tightens the engineering practices inside whatever process wraps around it.

FDD solves scale by putting a shared object model in front of the team before feature work starts, then keeping every feature traceable back to that model through a fixed five-process cycle. The model is what keeps a Class Owner on one floor and a Class Owner in a satellite office building against the same understanding of what a "Loan" or a "Policy" actually is.

Where FDD Came From

Jeff De Luca built FDD in the field, not in a textbook. In 1997 he was the project manager on PowerLender, a 15-month, 50-person banking software project in Singapore, and the method grew out of what actually worked to keep that project on schedule, according to a detailed account from IT Project Services.

Peter Coad, known for a technique called modeling in color, joined the project to run an upfront modeling exercise. He introduced De Luca to the idea of a fine-grained feature: a piece of functionality small enough to build, test, and demonstrate in days rather than weeks. De Luca took that idea and built the rest of the method's five processes around it.

De Luca, Coad, and Eric Lefebvre first described FDD publicly in chapter 6 of "Java Modeling in Color with UML" (1999), two years before the Agile Manifesto formalized the broader agile movement. Stephen Palmer and Mac Felsing later expanded the method into its own dedicated book, "A Practical Guide to Feature-Driven Development", published in February 2002, which is still the closer reference most FDD practitioners cite today. Its chapters walk through the five processes one per chapter, which is the clearest published confirmation of the structure below.

The Five FDD Processes

FDD runs on five processes. The first two happen once, near the start of a project, and set up everything else. The last three repeat, feature set by feature set, for the rest of the project, as summarized by Umbrex.

Develop an Overall Model

This is the process most agile teams skip, and it's the one that makes the rest of FDD work. A domain walkthrough brings in Domain Experts who know the business, not just the software, and the Chief Architect turns what they say into class diagrams. The output isn't a finished architecture, it's a shared reference everyone on the project can point back to when they disagree about what a term means.

Build a Features List

Once the model exists, the team functionally decomposes it. Subject areas break into business activities, and each business activity's steps become a features list. This is FDD's equivalent of a work breakdown structure, except every leaf item is a feature small enough to finish in about two weeks.

Plan by Feature

Features get sequenced by business priority and technical dependency, then assigned to a Chief Programmer, who pulls in whichever Class Owners hold the classes that feature touches. This looks closer to MoSCoW prioritization than to a single backlog owner's judgment call, since sequencing has to respect both the model's dependencies and the business's priorities at once.

Design by Feature and Build by Feature

A Chief Programmer picks a small set of related features and forms a temporary feature team from the relevant Class Owners. That team produces a detailed design (sequence diagrams, method signatures) and walks it through a design inspection before anyone opens an editor. Once the design clears inspection, Class Owners implement their classes, write unit tests, and submit the feature to code inspection. Once it passes, it's promoted to the build, and because ownership is fixed per class, there's no ambiguity about who's responsible for a regression.

What Counts as a "Feature" in FDD

A feature in FDD is a small, client-valued piece of function, not a story, not an epic, and not a task. FDD names every feature with a fixed template so the list stays scannable at a glance: an action, the result, and the object it acts on, in the form <action> the <result> {by | for | of | to} a(n) <object>.

"Calculate the total number of people" is the textbook example: calculate is the action, total is the result, number of people is the object. Umbrex's phrasing of the same pattern gives "Validate customer identity" and "Apply loyalty discount to invoice," which show the template holding up across very different domains.

Every feature has to be small enough to build in two weeks or less. If a piece of functionality doesn't fit, it isn't a feature yet, it's still a business activity waiting to be broken down further. That size discipline is what makes the milestone tracking in the next section meaningful: a "feature" that secretly takes six weeks breaks the whole reporting model.

This is worth comparing against how other frameworks size work. User stories describe a need from the user's perspective and get sized in story points; FDD features describe a function using a fixed grammar and get sized in days. If you're used to writing epics and stories, FDD's feature sits closest to a story, but the naming discipline is stricter than either.

The Six Milestones and How Progress Gets Tracked

FDD's most distinctive contribution to project reporting is that a feature's percent complete isn't a guess. Every feature passes through six milestones, and each milestone carries a fixed weight toward 100%, as laid out by TMS Outsource.

The first three milestones sit inside Design by Feature, the last three inside Build by Feature. Add the first three and you get 44%, meaning a feature that has cleared design inspection is already 44% done before a developer writes a single line of it. That number surprises people used to counting progress by story points closed, but it reflects something true about software: design decisions that survive inspection carry most of the risk out of a feature before coding even starts, the same reason a solid definition of done matters more than a task checklist.

Because every feature uses the same six weights, a program manager can roll individual feature percentages up into a subject-area total without asking anyone to estimate anything twice. That rollup is what FDD's Parking Lot chart visualizes: each subject area gets a labeled box, the box shows how many features it contains and what percentage of them are complete, and the whole chart fits on one page even on a project with hundreds of features.

FDD Roles

FDD assigns a fixed set of roles instead of leaving the team to self-organize, per the role breakdown from TMS Outsource. On a small project, one person often holds more than one role; on a project the size of the one that produced FDD, they're usually separate people.

Compare this against a RACI or DACI matrix: FDD's roles function like a RACI baked directly into the method rather than a document a project manager fills in separately. Every feature always has exactly one Class Owner responsible for it, which removes an entire category of the "who owns this" meetings that plague less structured projects.

How FDD Tracks and Reports Progress

Because every feature carries a milestone-weighted percentage, FDD reporting doesn't lean on velocity trends or burndown extrapolation the way Scrum does. A Chief Programmer reports the milestone each feature under their team has reached; the Development Manager rolls that up by subject area; the Parking Lot chart turns the rollup into something an executive can read in thirty seconds.

This works well specifically because features are small and their milestones are fixed. On a framework where "done" is defined per team or per sprint, rolling status up across dozens of teams means normalizing dozens of different definitions of done first. FDD skips that step, because its definition of done, the six milestones, never changes from feature to feature or team to team.

FDD vs Scrum vs XP

These three sit at different altitudes. FDD structures the whole project around a domain model and fixed roles, Scrum structures the team's process and cadence, and XP structures the engineering practices used to actually write the code. Many real projects combine pieces of more than one.

Teams running Scrum at scale sometimes borrow FDD's upfront modeling step to give multiple Scrum teams a shared domain reference, while teams running FDD often pull XP's technical practices, especially test-driven development and continuous integration, into the Build by Feature process. None of the three requires abandoning the others entirely.

Where FDD Fits and Where It Doesn't

FDD's biggest strength, the upfront model, is also its biggest cost. Building an accurate domain model takes real time from your most senior people before any feature ships, which is a hard sell on a project where the domain itself is still uncertain. It pays off fastest on the kind of project it was invented for: a large, well-understood domain where getting the model wrong once means getting a hundred features wrong the same way.

That tradeoff is also what separates FDD from a straight waterfall plan. The upfront model can look like a throwback to big-design-upfront documentation, but the five processes still ship working, inspected features on a two-week cadence rather than holding everything for one release at the end. For teams scaling FDD across many feature teams and programs at once, the Scaled Agile Framework (SAFe) can sit above it as a coordination layer, the same way SAFe accommodates XP practices at the team level.

FDD also assumes you can staff its roles for real. A "Chief Architect" who's really just a senior developer with an extra title won't produce a model strong enough to carry the rest of the method. If your team can't credibly fill Chief Architect, Chief Programmer, and Class Owner as distinct, seniority-appropriate roles, FDD will feel like process overhead without the payoff.

How to Adopt FDD on a Team

FDD is not something you bolt onto an existing sprint cadence overnight. It works best introduced roughly in the order the five processes assume.

Step 1: Run the domain walkthrough and build the overall model

Get your most senior technical person into the Chief Architect role and pull in real Domain Experts, people who understand the business, not just people who can read a requirements doc. Timebox the first model. It doesn't need to be perfect, it needs to be shared.

Step 2: Decompose the model into a features list

Work top-down: subject areas, then business activities inside them, then individual features named with the action-result-object template. Resist the urge to skip straight to a backlog of stories; the decomposition is what keeps the features list traceable back to the model. Building a workable list also leans on the same discipline as writing tight acceptance criteria, each feature needs a clear, testable definition before anyone starts designing it.

Step 3: Assign Class Owners and plan by feature

Every class in the model needs exactly one owner. Sequence the features list by business priority and technical dependency, then group features into work sets a Chief Programmer can lead through design and build together.

Step 4: Run design-by-feature and build-by-feature in short cycles

Keep feature teams temporary and small: a Chief Programmer plus the Class Owners whose classes a given feature touches. Hold real design inspections and code inspections instead of treating them as a formality; that's where FDD's quality actually comes from. Teams that already run Lean Software Development's eliminate-waste principle tend to adapt fastest here, since both methods treat unreviewed work in progress as risk sitting on the books.

Step 5: Stand up milestone tracking and the Parking Lot report

Don't wait until the project is in trouble to start reporting by milestone percentage. Set it up from the first feature set so the Parking Lot chart has real data behind it by the time anyone outside the team asks for a status update.

Common Mistakes Teams Make with FDD

FDD isn't the agile method most teams reach for first, and that's mostly a function of team size. Most software teams are small enough that Scrum's lighter process is a better fit. But on the kind of project FDD was built for, dozens of developers, a domain with real rules, and stakeholders who need an honest percentage rather than a sprint burndown, its five processes and fixed roles do something Scrum and XP don't attempt: they keep a hundred features traceable back to one shared model of the system.