The Agile Handbook

Feature-Driven Development (FDD): An Agile Approach to Software Development

Last updated on

Feature-Driven Development (FDD): An Agile Approach to Software Development

The Agile Method Built for Developers Who Think in Features, Not Stories

FDD was born in Singapore in the late 1990s on a 15-month project for a large bank. Jeff DeLuca and Peter Coad were brought in to rescue a project that had been running for three years and had nothing to show for it. They needed something structured enough to give 50 developers a coherent way to work, but iterative enough to deliver value continuously. What they built became Feature-Driven Development.

The context matters. FDD was designed for big teams on complex systems, not for two-person startups. If you’re running a small product team, Scrum or Kanban will likely serve you better. But if you’re coordinating 20-plus developers across a complex domain, FDD has structural advantages that are worth understanding.

What Makes FDD Different: The Feature List

Most Agile frameworks start with user stories. FDD starts with a domain model and a feature list, and this changes the entire character of the work.

In FDD, a feature has a specific form: <action> the <result> <by|for|of|to> a(n) <object>. For example: “Calculate the total interest for a loan account.” This template forces precision. You can’t write “make the dashboard better” as an FDD feature — you have to decompose it into specific, client-valued functions.

The feature list is grouped by functional area and subject matter, creating a hierarchical view of the product that helps large teams understand how their work fits together. This is something user story backlogs handle poorly at scale — when you have 400 user stories in a flat list, nobody has a mental model of the system.

A senior developer I worked with put it well: “With user stories, I knew what to build next. With FDD, I understood why.”

The Five-Process Model: Where It Gets Opinionated

FDD defines five sequential-but-overlapping processes:

Develop an Overall Model — A high-level domain model built collaboratively between domain experts and developers. This is more upfront investment than Scrum advocates for, but it pays dividends on complex systems. Skipping this is why teams end up with domains modeled around database tables rather than business concepts.

Build a Features List — Decompose the model into features using the standard form. A rule of thumb: features should be completable in two weeks or less. If they’re not, decompose further.

Plan by Feature — Chief programmers (more on this role shortly) take ownership of feature sets and plan their sequence. This is where FDD diverges most sharply from Scrum — there’s explicit senior technical ownership of chunks of the system.

Design by Feature — For each feature or feature set, a small team does a design walkthrough. This is a lightweight design review, not an architecture astronaut exercise. The goal is to catch design mistakes before coding, not to produce comprehensive design documents.

Build by Feature — Code, test, integrate. The chief programmer reviews and promotes code to the main build. This is the shortest phase for any individual feature, typically a few days.

The Chief Programmer Role: Controversial, But Not Wrong

FDD distinguishes between class owners (developers responsible for specific classes) and chief programmers (senior developers who lead feature sets). This hierarchy is antithetical to the Agile value of self-organizing teams, and it generates genuine pushback.

My take: in a team of experienced, senior developers, you may not need explicit chief programmers. But in a team with mixed experience levels working on a complex system, having clear senior technical ownership over feature areas is the difference between coherent architecture and chaos.

The alternative to deliberate ownership is accidental ownership — where the most aggressive or most senior developer ends up owning everything by default. FDD at least makes this explicit and gives other developers a development path.

Where FDD Breaks Down

It assumes a stable domain. The upfront domain modeling works on systems where the business domain is well understood. If you’re in discovery mode — trying to figure out what users actually need — FDD’s upfront investment is premature.

It requires experienced developers. Class ownership and technical leadership roles assume your team has people who can make sound design decisions. Junior-heavy teams will struggle with the design phases and produce poorly modeled domains.

It lacks ceremony around stakeholder feedback. Scrum’s Sprint Review and Retrospective create regular checkpoints with stakeholders and for team reflection. FDD doesn’t prescribe these. Teams using FDD need to deliberately add feedback loops that the methodology doesn’t build in.

The reporting model can be gamed. FDD tracks progress as percentage completion of features. If features aren’t scoped precisely, teams end up with “90% done” features that never quite finish. The “90% complete” trap is common in FDD implementations without rigorous feature sizing.

When to Actually Use FDD

Use FDD when:

Don’t use FDD when:

The Takeaway

FDD is underrated in Agile circles, partly because it’s less fashionable than Scrum and partly because it demands more upfront structure than most Agile advocates are comfortable recommending.

But for large teams on complex domains, that structure is an asset. The feature list is a better organizing principle than a flat backlog for big systems. Domain modeling as a team activity builds shared understanding that user story writing rarely achieves.

If your team is drowning in a flat backlog of hundreds of stories with no coherent picture of the system, FDD’s domain modeling and hierarchical feature organization might be exactly the clarity you need.

Start by trying the feature template: <action> the <result> by/for/of/to a(n) <object>. Apply it to your current backlog items and see how it changes the conversation about what actually needs to be built.