Skip to content

Feature-Driven Development

An iterative software-development method that builds an overall domain model and feature list, then plans, designs, inspects, builds, and integrates small client-valued features in short cycles.

Version
v1 · 2026-09-28 · History
Domain-specific #
9422
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomain
Software Development Methodology → Computer Science & Software Engineering
Aliases
FDD, Feature driven development, Feature-driven software development

Core Idea

Feature-driven development organizes a project around small, client-valued functions inside a shared domain model. It begins by developing an overall model and deriving a categorized feature list from subject areas, business activities, and activity steps. Features are expressed as concrete functions and are decomposed when too large for a short implementation cycle, conventionally about two weeks.

The remaining processes repeat by feature: plan ownership and sequence, design a small feature set with a chief programmer and relevant class owners, inspect the design, implement and test the affected classes, inspect code, and promote the completed feature into the main build. Class ownership protects conceptual integrity while temporary feature teams cross those ownership boundaries. Milestones make progress visible through completed artifacts rather than a vague percentage of a large component.

Structural Signature

Sig role-phrases:

  • Domain model — Provides a shared object-oriented representation in which features will be designed. It is required foundation. Counterfactual: A backlog without the overall model omits FDD's model-driven starting point.
  • Categorized feature list — Decomposes business activities into small client-valued functions. It is defining work structure. Counterfactual: Large components or technical tasks alone do not supply the feature unit.
  • Feature plan and ownership — Sequences work and assigns classes or feature sets to responsible developers. It is required coordination. Counterfactual: Iteration without declared ownership loses a characteristic FDD control mechanism.
  • Design-by-feature team — Temporarily combines a chief programmer and class owners to design a small feature set. It is required iterative role. Counterfactual: A permanent component team is not automatically an FDD feature team.
  • Inspection and build-by-feature — Reviews design/code, tests changes, and promotes completed features to the main build. It is required delivery loop. Counterfactual: Declaring a feature complete before inspected, tested integration breaks the method's completion rule.
  • Feature milestones — Report progress through evidence-bearing events rather than undifferentiated percentage estimates. It is characteristic visibility. Counterfactual: A milestone label without completed artifacts becomes nominal reporting.

What It Is Not

  • FDD is not every project that uses a backlog of things called features.
  • It is not simply short iterations; the overall model, categorized feature list, ownership, and design/build-by-feature processes are constitutive.
  • A technical task such as upgrade a library is not automatically a client-valued feature, though it may support one.
  • Individual class ownership does not mean one developer designs every cross-class feature alone.
  • Closest near-miss. Scrum organizes work through roles, events, and product/sprint backlogs; FDD is distinguished by its domain model, feature decomposition, class ownership, and design/build-by-feature processes.

Scope of Application

  • Domain-rich software. An overall object model gives many feature teams a common vocabulary and class structure.
  • Large development groups. Class ownership and feature teams coordinate parallel work while retaining responsibility.
  • Incremental delivery. Small features move through design, inspection, code, test, and integration repeatedly.
  • Progress reporting. Named milestones and completed features expose status at finer granularity than component percentages.

Clarity

A project should be called FDD only when the five processes and their work products are observable. A two-week timebox does not by itself make an item a feature; it must express client-valued function and be connected to the model. Milestone percentages should summarize completed evidence, not substitute for it. Adaptations can be legitimate, but removing several load-bearing roles should be described as influence rather than full method identity.

Manages Complexity

The feature list turns a large domain into small deliverable slices, while the overall model keeps those slices from becoming unrelated patches. Class ownership localizes stewardship, and feature teams reassemble the owners needed for one vertical function. The architecture can become rigid if the initial model is treated as final, so model refinement and refactoring must remain visible as features expose new understanding.

Abstract Reasoning

  1. Walk through the system scope and build reviewed models for the important domain areas.
  2. Merge them into an overall model and derive a categorized list of small client-valued features.
  3. Plan feature order and assign class or feature-set ownership according to dependency and capacity.
  4. Form a feature team, produce a design package, and inspect it before implementation.
  5. Implement across owned classes, unit-test and inspect the code, and promote the feature to the main build.
  6. Report milestone evidence and revise the model and feature list when delivery reveals new domain structure.

Knowledge Transfer

FDD transfers among software projects that can express work as small client-valued functions within a coherent domain model. A research prototype or infrastructure program may borrow feature decomposition or inspections without supporting the whole method. Beyond software, planning by small outcomes is analogous, but class ownership, code inspection, and main-build integration are constitutive domain accents.

Examples

Canonical

A team models a banking domain, derives a feature such as 'calculate the total of a sale,' assigns affected classes, completes a feature-team design inspection, codes and inspects the classes, tests them, and promotes the feature to the main build.

Mapped back: completion → inspection, test, build promotion; model → domain objects; roles → chief programmer and class owners; unit → client-valued feature.

Applied / In Practice

A team that calls every two-week sprint a feature cycle but has no overall model, feature-list decomposition, class ownership, or design-by-feature activity is agile but not thereby practicing FDD.

Mapped back: classification → not sufficient for FDD; missing → model and five processes; present → short iteration.

Structural Tensions

T1 — Overall Model Coherence versus Incremental Feature Delivery. Early modeling coordinates class structure, while frequent delivery demands that the model remain revisable rather than exhaustive.

Diagnostic: How much modeling is sufficient to guide the next feature without becoming a long design phase?

T2 — Individual Class Ownership versus Cross-Class Feature Teamwork. Persistent owners protect conceptual integrity, while each client feature usually spans classes and requires temporary collaboration.

Diagnostic: Do ownership rules enable review and integration rather than create bottlenecks?

Structural–Framed Character

Feature-Driven Development is framed-leaning with a repeatable process architecture. The five processes, feature unit, ownership, and milestones give it structure. Client value, domain boundaries, team roles, coding standards, and acceptable adaptation depend on organizational practice.

Structural Core vs. Domain Accent

The skeleton is staged decomposition followed by repeated delivery loops around small outcomes. Software engineering supplies domain models, classes, code ownership, inspections, unit tests, configuration management, and builds. Removing those elements yields generic incremental project management.

This entry presupposes Iteration.

  • Approved root. No reviewed parent currently entails this five-process model-and-feature development method.

  • Related — iteration, decomposition, inspection, and ownership. They illuminate practices but do not replace the integrated FDD method.

Relationships to Other Abstractions

Local relationship map for Feature-Driven DevelopmentParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Feature-DrivenDevelopmentDOMAINPrime abstraction: Iteration — presupposesIterationPRIME

Current abstraction Feature-Driven Development Domain-specific

Parents (1) — more general patterns this builds on

  • Feature-Driven Development presupposes Iteration Prime

    Feature-Driven Development presupposes Iteration because its method repeatedly plans, designs, inspects, builds, and integrates small client-valued features.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Feature-Driven Development sits in a crowded region of the domain-specific corpus (39th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Organizational Patterns & Management Concepts (29 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With

  • Scrum. Tell: Organizes product work through roles, events, and backlogs rather than FDD's overall model, class ownership, and design/build-by-feature sequence.
  • Behavior-driven development. Tell: Specifies behavior through examples and executable scenarios; it is not the same project process.
  • Feature branch workflow. Tell: Is a source-control practice and does not define client-valued feature decomposition or feature teams.
  • Waterfall. Tell: Sequences broad lifecycle phases once, whereas FDD repeats design and build for many small features after initial modeling.

References

  • Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Feature-driven_development (revision 1316374257).
  • Preserved source candidate: http://agilemanifesto.org/principles.html
  • Preserved source candidate: http://www.featuredrivendevelopment.com/
  • Preserved source candidate: http://www.nebulon.com/fdd/index.html
  • Preserved source candidate: http://www.sitepoint.com/article/successful-development
  • Preserved source candidate: http://www.methodsandtools.com/archive/archive.php?id=19
  • Preserved source candidate: http://www.agilemodeling.com/essays/fdd.htm
  • Preserved source candidate: https://web.archive.org/web/20071102073447/http://www.bettersoftwarefaster.com/index.htm
  • Preserved source candidate: http://www.se-radio.net/2008/01/episode-83-jeff-deluca-on-feature-driven-development/

The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.