FDD is older than the word Agile. A large Singapore bank project produced it in 1997 (Dr. Dobb’s), and 17 practitioners did not publish the Agile Manifesto until February 2001 (PMI’s Disciplined Agile site). So a Feature-Driven Development vs Agile comparison is really one method set against the family that formed around it, which in practice means FDD against Scrum, Kanban, Extreme Programming and the rest.
FDD suits large, long-running systems with a stable domain. The other frameworks suit teams whose requirements keep shifting.
The main split is where design happens. FDD builds an overall domain model first and then delivers feature by feature, while Agile frameworks let design emerge during delivery.
Is Feature-Driven Development Agile?
Yes, mostly. FDD counts as an Agile method, though it keeps several practices that most Agile frameworks dropped.
Most of what gets called the Agile methodology is really a family of frameworks, Scrum, Kanban, Extreme Programming and a few others, all hung on the values of a 2001 manifesto. There is no single Agile method to compare against.
FDD started in 1997 on that Singapore bank project, according to Dr. Dobb’s. Wikipedia’s entry on the method puts the project at 15 months and 50 people, with Jeff De Luca designing the process and Peter Coad’s object modeling shaping its first step.
The method reached print in 1999 in Java Modeling in Color with UML, by Coad, Lefebvre and De Luca. Palmer and Felsing’s A Practical Guide to Feature-Driven Development (Prentice Hall, 2002) later pulled it away from Java modeling and turned it into a standalone method.
Seventeen practitioners wrote the Agile Manifesto in February 2001, per PMI’s Disciplined Agile site. FDD was already four years old by then.
How FDD scores against the four Manifesto values
The ratings below are a judgment call, not a standard.
| Manifesto value | FDD practice | Fit |
|---|---|---|
| Individuals and interactions over processes and tools | 5 fixed processes and 6 defined roles, but feature teams re-form per batch | Partial |
| Working software over comprehensive documentation | Features ship in 2 weeks or less, but the model and inspections add documents | Partial |
| Customer collaboration over contract negotiation | Domain experts join the modeling team, and features are client-valued | Strong |
| Responding to change over following a plan | Overall model and plan are built before feature work starts | Weakest |
FDD fits best on customer value and delivery cadence. It fits worst on planning, because the model and the plan come first.
Where FDD departs from mainstream Agile
Every class in FDD has exactly one owner, while XP uses collective ownership (DZone). FDD also prescribes domain object modeling, and Scrum prescribes no design technique at all (PM Study Circle). Features are sized to finish in two weeks or less, so there is no fixed calendar sprint.
People who judge Agile by extreme programming tend to miss this, a point StickyMinds makes about FDD directly. FDD starts from a model and keeps formal inspections, and XP does neither.
How the FDD Processes Work
The first three processes set the project up once. The last two repeat for every batch of features.
- Develop an overall model. Domain experts, the chief architect and chief programmers build a high-level object model, drawing on Peter Coad’s approach to object modeling.
- Build a features list. The team breaks the model into subject areas, feature sets and individual features.
- Plan by feature. Feature sets are sequenced by business value and assigned to chief programmers, and classes go to individual owners.
- Design by feature. A chief programmer picks the features for the next cycle, forms a feature team from the relevant class owners and holds a design inspection.
- Build by feature. Class owners write and unit test the code, pass a code inspection and promote the feature to the build.
Roughly 75 percent of the effort on an FDD project goes into processes 4 and 5, per Dr. Dobb’s.
Processes 1 to 3 are the cost of entry. After that, delivery is mostly a loop.
Inspections and builds inside each cycle
Every feature passes a design inspection before coding and a code inspection before it joins the build. Code inspection is a formal version of the code review process that most teams already run on pull requests.
FDD does not prescribe a build regime. It assumes regular builds happen and requires that the feature team delivers tested, inspected code, according to DZone’s two-part introduction.
Feature vs User Story: What Each Method Counts as a Unit of Work
FDD writes every feature as an action, a result and an object, and keeps it small and client-valued.
That feature-driven development naming pattern keeps the list easy to scan. “Calculate the total of a sale” and “Validate the password of a user” are the standard examples (Wikipedia).
At the top of the hierarchy sits the major feature set, which is a subject area taken from the overall model. Under it, a feature set groups the features that serve one business activity. The feature itself is the smallest unit, finished within two weeks.
Scrum and XP work from user stories instead. A story lives in the product backlog and counts as ready when the team can finish it within one sprint, per the 2020 Scrum Guide.
ActiveCollab notes that an FDD feature looks more like a Scrum user story than like a feature in the usual Agile sense. The word gets bigger in the Scaled Agile Framework, where a feature must fit inside a single Program Increment and stories are the pieces that fit in a sprint.
So “feature” covers three different sizes. An FDD feature is two weeks at most. A Scrum backlog item has to be small enough to finish in one sprint (one month or less), and a SAFe feature must fit inside one Program Increment.
Match the sizes before comparing feature counts across methods. A count of 200 features means something different in each of them.
How FDD Roles Compare With Scrum Roles
FDD defines 6 primary roles and gives every class a single owner, which is a lot more structure than Scrum’s 3 accountabilities.
The 2020 Scrum Guide names a product owner, a Scrum Master and developers. It calls them accountabilities rather than roles, and describes a Scrum Team as typically 10 or fewer people.
FDD’s six primary roles are project manager, chief architect, development manager, chief programmer, class owner and domain expert, per Dr. Dobb’s. It also defines supporting roles on top of those.
What the FDD roles actually do
The chief programmer selects the features for a two-week cycle and leads the feature team. Each class owner answers for the consistency, performance and conceptual integrity of one class (Wikipedia). A feature team is just the set of class owners whose classes a feature touches, formed per batch.
Closest Scrum counterpart
| FDD role | Nearest Scrum match | Difference |
|---|---|---|
| Chief programmer | Developer | Leads each feature team and picks its features |
| Class owner | Developer | Owns specific classes, not shared code |
| Chief architect | None | Scrum names no architect |
| Development manager | Scrum Master | Runs day-to-day development and resolves resource conflicts |
| Domain expert | Product owner | Feeds the model, does not order the backlog |
The nearest match to the development manager is the Scrum Master. A Scrum Master is accountable for the team’s effectiveness and coaches it, while the development manager runs day-to-day coordination.
The strain shows up around the chief programmer, because FDD leans hard on that one person. They have to coordinate, lead design and mentor, as Lucid points out. Planning also has to account for class owner availability, since a feature cannot move without the owners of its classes.
Iteration Length, Progress Tracking and Reporting
FDD tracks progress per feature against weighted milestones, while Scrum looks at the Sprint Goal and the Increment. Kanban has no iteration to track at all, and XP simply ends every iteration with working software.
How long one cycle runs
Planview puts FDD at one feature every 2 to 10 days, against Scrum sprints that typically last two weeks and sometimes four.
The top of that range matches the size limit the method sets for a feature, so the sources agree. A feature that will not fit gets split, not stretched.
The feature is the time box in FDD. Sprint-based frameworks flip that around, so the sprint is the box and backlog items get fitted inside it.
Atlassian describes Kanban as ongoing flow, not work planned only in fixed cycles.
Milestone weights
Each feature has 6 milestones, 3 in design by feature and 3 in build by feature. A feature is 44% complete when coding starts (domain walkthrough 1%, design 40%, design inspection 3%). Coding then carries 45%, code inspection 10% and promotion to the build 1%.
The 44% figure comes from Wikipedia’s FDD entry and is repeated in University of Mosul course notes. The remaining weights follow standard FDD training material.
Read together, the weights show how much of an FDD feature is design work.
What each method reports
FDD reports percent complete per feature and rolls it up at every level to the project (Planview). Scrum shows the Increment against the Sprint Goal at each Sprint Review. Kanban reports four flow metrics, which are cycle time, throughput, WIP and work item age (Kanban Guide for Scrum Teams), and XP reports working software at the end of every iteration.
Tooling matters here. As of the Azure Boards documentation reviewed in October 2026, a Feature groups related stories, and a User Story moves through New, Active, Resolved, Closed and Removed.
No state in that default Agile process matches a design inspection. Tracking FDD’s six milestones in Azure DevOps means customizing the process states.
Upfront Modeling and Documentation: FDD vs Emergent Design
FDD builds an overall domain model before the first feature ships. Agile frameworks let design emerge from working software instead.
What FDD documents
Each feature gets a design package made up of an updated object model, sequence diagrams, and class and method prologues, according to Wikipedia and University of Mosul course notes.
Planview says FDD values documentation more than Scrum or XP do. The first process, domain object modeling, is a form of software modeling that every later feature builds on.
What emergent design relies on
Scrum treats the product backlog as an emergent, ordered list (2020 Scrum Guide). XP rules call for the simplest design that passes the tests, and Kanban prescribes no design practice at all.
XP’s answer to design drift is constant code refactoring, so the code itself carries the design.
Sources disagree on how model-driven FDD is
PM Study Circle describes a phased approach that starts with the domain model. DZone’s introduction argues the model is central but the project is still requirement-driven, like Scrum or XP.
Both readings fit the process. The difference is emphasis. The model comes first in FDD, and the requirement-driven loop runs after it.
What the model costs
Starting from a model pays off when the domain is stable and many developers share one vocabulary. The cost is initial overhead, and changes that touch several features or the overall model are hard to absorb (Evozon).
Emergent design pays off when requirements move. What it costs you is a shared model, since none exists unless the team builds one.
Feature-Driven Development vs Scrum, Kanban and XP Side by Side
Of the four, FDD and XP are the ones that say how code should be designed and owned, and Scrum and Kanban leave engineering practice to the team.
XP is the most specific Agile framework on engineering practice, per Cleveland State University’s project management textbook. FDD is specific about design and ownership instead.
How the work is organized
| Method | Unit of work | Cadence | Code ownership |
|---|---|---|---|
| FDD | Feature (action, result, object) | Per-feature cycles | Individual class owners |
| Scrum | Product backlog item | Fixed-length sprint | Not prescribed |
| Kanban | Card on a board | Continuous flow | Not prescribed |
| XP | User story | Short iteration ending in working software | Collective |
The Kanban row is the odd one. It adds WIP limits and flow metrics to any workflow, including a Scrum team’s, according to the Kanban Guide for Scrum Teams.
How progress, roles and design are handled
| Method | Roles | Progress measure | Design approach |
|---|---|---|---|
| FDD | Chief programmer, class owners, chief architect | Weighted milestones per feature | Overall model first |
| Scrum | Product owner, Scrum Master, developers | Increment against Sprint Goal | Left to the team |
| Kanban | None prescribed | Cycle time, throughput, WIP, age | Left to the team |
| XP | Programmers and a customer | Working software each iteration | Simple design, refactoring |
The Scrum framework is the most prescriptive of the four on meetings, with five defined events in its guide.
What each one prescribes and leaves open
FDD prescribes design and ownership and leaves build tooling open, since it avoids mandating any build regime. Scrum fixes events and accountabilities but says nothing about engineering practice. Kanban asks for WIP limits and visible flow and leaves roles and cadence to the team. XP is close to the reverse of Scrum, with firm engineering practices and product management left open.
Which One Fits Your Team Size and Project?
Choose FDD for large, long-running systems with a stable domain. Choose Scrum, Kanban or XP when requirements shift or the team is small.
A decision path by project trait
Picking among software development methodologies works best as a sequence of checks.
- Is the work a continuous stream, such as support tickets or operations requests? Use Kanban.
- Is engineering discipline the main risk, with a small team that can pair and test first? Use XP.
- Is the system large, the domain stable and the team big enough to name class owners? Use FDD.
- Does one team own one product with priorities that change often? Use Scrum.
Run the checks in that order, because the narrow cases come first and Scrum covers the wide middle. This path is a rule of thumb built from the fit statements in the sources above, not a published standard.
What adoption data shows
Scrum is the most widely adopted approach, at 63% in Digital.ai’s 17th State of Agile report (2024). The 18th report (2025) did not ask about team-level frameworks, so 63% is still the latest Scrum figure from the series.
The 17th report also found that 52% of small organizations say enterprise Agile works well, against 43% of larger companies.
Neither figure isolates FDD, so they cannot prove it performs better at scale. They do show where the default starts to strain.
How each approach scales
Scrum scales by adding teams. Under the 2020 Scrum Guide, several teams on one product share a single Product Goal, one product backlog and one product owner.
FDD scales by forming feature teams from class owners across a larger group. DZone’s introduction says anyone applying Agile to larger projects and teams should understand it.
The same DZone piece adds a caution. A small team of disciplined, skilled developers is likely to succeed whichever method it picks, and the piece also calls FDD just as applicable for small teams tackling a non-trivial domain. A team that already succeeds without FDD’s roles and inspections may find they add cost without adding much.
When FDD Does Not Fit
FDD is a poor fit for small teams. It also struggles when requirements keep moving, or when the system has no stable domain to model.
Small projects and solo developers
ProductPlan lists poor efficiency on smaller projects as a core weakness.
Lucid goes further and says FDD does not work for a single developer, because one person cannot fill the separate roles the method assumes.
Moving requirements
A 2017 arXiv comparison of methodologies, “To Agile, or not to Agile”, notes that FDD needs a substantial upfront requirements effort to produce a plan that will not change much. If it does change, the project needs deep refactoring.
Every model change then touches the feature list and the plan. Teams in that position need a formal change request management routine to keep the three in step.
Signs the model-first start is costing too much
- The overall model changes after most features
- The feature list is rewritten every cycle
These are judgment calls drawn from the documented failure mode, not published thresholds.
Strengths and costs of FDD at a glance
What works in its favor
- It scales to large, long-running projects with defined roles (Planview)
- Status reporting exists at every level, down to a single feature (Planview)
- Inspections catch defects before code reaches the build (Wikipedia)
- Client-valued features keep the list readable in business terms
What it costs you
- Modeling overhead comes before the first feature ships (Evozon)
- Changes that hit several features or the overall model are hard to absorb (Evozon)
- It is a weak fit for small projects and solo developers (ProductPlan, Lucid)
- The standard reference text, Palmer and Felsing, dates from 2002, before Git-based pull requests and CI pipelines became routine
Feature-Driven Development vs Agile FAQ
Can FDD and Scrum be used together?
Yes. ActiveCollab says both can run on big, complex software projects.
One workable split keeps FDD’s overall model and feature list as the plan, then delivers the features in sprints.
Does FDD use story points?
Not as a requirement. FDD reports progress through six weighted milestones per feature and sizes each feature to fit a short cycle.
A team that wants points can still record them on the story items in its tracker.
Which tools can track FDD work?
Any tool with parent and child work items fits. Azure DevOps nests Epics, Features and User Stories, which map loosely onto FDD’s major feature sets, feature sets and features.
Expect to customize the workflow states to carry the milestones.
Is FDD still used today?
Yes, mainly on large, long-running projects. ProductPlan reports wider use in larger organizations, and Planview still positions it for complex, long-term work.
The surveys reviewed for this article do not break out an FDD share.
How long does it take a team to adopt FDD?
No published benchmark exists in the sources reviewed.
The structure explains the lag, though. The first three processes (overall model, features list, plan) must finish before any feature ships, so the first delivery lands later than in a framework that starts building at once.
Moving From Scrum or Kanban to FDD Without Stalling Delivery
A Scrum or Kanban team adopts FDD by piloting one feature set on its existing board before changing roles, cadence or tooling.
Start with a feature set that has stable requirements. Name class owners for its classes only, and add milestone states after the first cycle. Ownership comes before milestones because a milestone has to belong to someone.
At Planview’s pace of one feature every 2 to 10 days, a two-week sprint holds 1 to 5 features, which sizes the pilot.
The pilot trades swarming flexibility for traceable ownership. That position holds until a tracker ships FDD milestone states by default, which Azure Boards did not as of October 2026.
Teams still choosing a starting point can first compare how Kanban and Scrum differ.
- MongoDB Cheat Sheet - October 20, 2026
- Adding AI Video Generation to a Software Product: Architecture, Cost Guardrails and QA - October 20, 2026
- Show Hidden Characters, Spaces, and Line Endings in Notepad++ - October 19, 2026
