Feature-Driven Development

Also known as: FDD

framework · computer science · organizing-schema

Iterative development methodology organized around designing and building client-valued features in short iterations.

Feature-Driven Development (FDD) is the agile software-development methodology developed by Jeff De Luca with Peter Coad during a 1997 Singapore banking-software project, articulated in Peter Coad, Eric Lefebvre, and Jeff De Luca's Java Modeling in Color with UML (1999) and consolidated in Stephen Palmer and John Felsing's A Practical Guide to Feature-Driven Development (2002). FDD organizes development around small client-valued features (each completable in two weeks or less) discovered through systematic domain modeling. The methodology comprises five processes: Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature, Build by Feature. FDD distinguishes itself from Scrum and XP through its emphasis on upfront domain modeling and explicit feature-team structures with class ownership. While less prominent than Scrum or XP, FDD has had substantial adoption in larger-scale enterprise contexts requiring more upfront architectural planning than lightweight agile methods provide.

Originators

Jeff De Luca (foundational lead author, Singapore banking project 1997); Peter Coad (foundational co-author, color modeling and Java Modeling in Color with UML 1999); Stephen Palmer & John Felsing (foundational consolidation in A Practical Guide to Feature-Driven Development 2002); intellectual antecedents in domain-modeling tradition (Coad's earlier object-oriented work), use-case modeling, broader 1990s lightweight-methods movement, Singapore banking-project specific organizational context; Subsequent development through FDD-community practice, modest training infrastructure, integration with broader domain-driven-design tradition (Eric Evans's Domain-Driven Design 2003 has substantive parallels though developed independently) high

Year / Decade

1997 (Singapore banking project initial development); 1999 (Java Modeling in Color with UML); 2002 (Palmer-Felsing Practical Guide); ongoing development high

Primary sources

Coad, P., Lefebvre, E. & De Luca, J. (1999). Java Modeling in Color with UML: Enterprise Components and Process, Palmer, S.R. & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development, Highsmith, J. (2002). Agile Software Development Ecosystems (covering FDD in broader agile-family context), FDD community publications and De Luca's ongoing consulting practice high

Core components

Five FDD processes: (1) Develop an Overall Model — domain modeling with domain experts and chief architects, producing class diagrams using color modeling (party/place/thing, role, description, moment-interval)
(2) Build a Features List — comprehensive features list categorized by subject area, business activity, and feature
(3) Plan by Feature — feature ownership assignment and milestone scheduling
(4) Design by Feature — chief programmer team designs features with class-ownership boundaries
(5) Build by Feature — implementation, code inspection, promotion to build
Feature granularity: each feature small enough to complete in two weeks or less, expressed as <action> <result> <object> (e.g., 'calculate total of a sale')
Class ownership: each class has single owner responsible for design and implementation, distinguishing FDD from collective-code-ownership tradition in XP
Feature teams: dynamic teams formed around features, drawing from class owners
Chief programmer role: senior developer who guides feature design and mentors team members
Color modeling: class-diagram conventions using colors to indicate archetype (pink = role, blue = description, yellow = moment-interval, green = party/place/thing) — distinctive FDD modeling tradition
Progress reporting: percent-complete tracking against features list with milestones at design-by-feature and build-by-feature completion
Application contexts: enterprise software development with substantial domain complexity, particularly banking, insurance, and other regulated industries

Primary use case

Agile software-development methodology for enterprise contexts with substantial domain complexity; applied principally in: banking software development (original Singapore context), insurance software, regulated-industry application development; intellectual reference for feature-oriented and domain-modeling agile practice; academic and professional reference in agile software development, domain-driven design, and software-engineering methodology literature; complementary to (or contrasting with) Scrum, XP, DSDM, Crystal, and broader Agile-Manifesto family; modest training and certification infrastructure compared to Scrum/XP.

Common criticisms

FDD adoption has been substantially smaller than Scrum and XP, with practitioner debate about whether FDD's distinctive emphases (upfront domain modeling, class ownership, color modeling) genuinely improve outcomes versus produce additional ceremony that lighter-weight agile methods avoid
the class-ownership model contradicts collective-code-ownership principles foundational to XP and subsequent agile practice, with critics arguing single-owner classes produce knowledge silos and bus-factor risk that distributed-ownership approaches mitigate
the upfront overall-model phase has been argued by lightweight-agile advocates to produce big-design-up-front anti-pattern that the broader agile movement explicitly rejected, reintroducing waterfall-style upfront commitment that subsequent iterative development cannot easily revise
the chief-programmer role has been argued to reproduce hierarchical software-team structures that flat agile-team models replaced, with implications for team autonomy and decision-making that some agile practitioners find regressive
color modeling, while a distinctive FDD contribution, has been argued to add modeling overhead without clear corresponding benefit in software outcome — the technique has had limited adoption outside FDD communities
empirical evidence on FDD effectiveness versus alternative agile methodologies is sparse, with most agile-methodology comparison research focusing on Scrum, XP, and broader Agile adoption rather than FDD specifically
cross-industry applicability has been argued to be uneven — FDD's enterprise-banking-context origin produces some institutional assumptions that may not transfer to other software-development contexts
integration with modern DevOps and continuous-deployment practices has been incompletely worked out in canonical FDD literature, with the methodology's explicit milestones (design complete, build complete) fitting awkwardly with continuous-flow development
training and certification infrastructure is substantially less developed than Scrum's, limiting professional-development pathways into FDD-specific practice.

Lineage

Child of: The Agile Manifesto
Siblings: Crystal Methods, Extreme Programming, DSDM