Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsFeature-Driven Development (FDD) is a structured, iterative software development process that organizes delivery around small, client-valued features. The team first builds a shared model of the problem domain, lists and plans features, then repeatedly designs and builds selected features. FDD’s five processes provide the roadmap; supporting practices such as inspections and regular builds help teams coordinate and verify delivery.
What Feature-Driven Development means
In FDD, a feature represents functionality described in terms of the problem domain—the work users or clients need done—not merely a programming task. Organizing work this way gives the team a common vocabulary for planning and tracking increments of useful functionality.
FDD combines early shared modeling and planning with incremental design and construction. The first three processes establish the model, feature list, and plan; the last two recur as the team takes features through design and implementation.
The five FDD processes
- Develop an Overall Model. Domain experts and developers work together to create a high-level model of the problem domain. This shared view helps the team understand the system it is building.
- Build a Features List. The team organizes desired functionality into features. These are expressed in domain terms so the list describes deliverable behavior rather than only technical components.
- Plan by Feature. The team sequences feature work and assigns responsibility. The feature list becomes a basis for organizing the delivery effort.
- Design by Feature. For a selected feature or group of related features, the team develops the design needed to implement it.
- Build by Feature. The team implements and integrates the selected feature work, advancing it through the applicable checks and into the build.
Jeff De Luca characterizes the first three as essentially one-time startup processes, while Design by Feature and Build by Feature are incremental construction processes. This means FDD includes up-front modeling and planning, but it does not treat design and implementation as a single phase completed once for the entire project. De Luca’s description of the process explains this distinction.
#1 Best Overall
How FDD supports feature delivery
The five processes are supported by practices that address shared understanding, responsibility, quality checks, integration, and visibility. The FDD guide’s contents identify the following practices:
- Domain object modeling helps the team develop and maintain a shared view of the problem domain.
- Class ownership makes responsibility for classes explicit, while feature teams bring the relevant people together to work on selected features.
- Inspections provide review points for design and code rather than relying on compilation alone.
- Regular builds integrate work on an ongoing basis. Configuration management helps control the project’s evolving software and related assets.
- Reporting and visibility of results make progress observable to the team and stakeholders.
These practices work together: a model and feature list give work a shared context, assignment clarifies responsibility, inspections check intermediate work, and builds and reporting help expose integration status and progress.
What “done” means: the six feature milestones
FDD’s site identifies six milestones for a feature: Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build. These milestones distinguish creating code from delivering integrated functionality.
- Domain Walkthrough
- Design
- Design Inspection
- Code
- Code Inspection
- Promote to Build
Promotion matters because a feature that compiles has not necessarily been integrated into the build as delivered functionality. In a 2003 Q&A, FDD author Jeff De Luca explains that a clean compile is implementation, not proof that the function has been delivered; the milestone sequence makes the transition into the build explicit. De Luca’s explanation of feature milestones addresses why Promote to Build is a milestone.
Recommended Free Tools
When to consider FDD
FDD may suit teams that can bring domain experts and developers together to form a shared model, express work as client-valued features, and use explicit assignments, inspections, and build practices. Its structure is particularly relevant when stakeholders need progress organized around recognizable functionality rather than only technical tasks.
Whether FDD fits a particular project depends on its domain, team arrangements, and delivery needs. The process description alone does not establish that it guarantees accurate estimates, project success, a specific team size, or better outcomes than another approach. To compare methods responsibly, examine how each handles domain modeling, work organization and estimation, integration frequency, ownership, inspections, and reporting.
Rank #4
A book for a deeper implementation guide
For a fuller treatment of the method, A Practical Guide to Feature-Driven Development by Stephen R. Palmer and Mac Felsing covers the five activities, roles, practices, project suitability, and adaptation, according to its publisher. The publisher’s book page provides its listing.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
