Feature driven development
Feature Driven Development (FDD) is an agile software development methodology that organizes work around features - small, client-valued pieces of functionality. Developed in the late 1990s by Jeff De Luca, FDD provides more structure than some agile approaches while maintaining the flexibility to adapt to changing requirements.
Why it matters
FDD bridges the gap between traditional heavyweight methodologies and lighter agile approaches. For organizations that need more predictability than Scrum offers but more flexibility than waterfall allows, FDD provides a middle path. It's particularly effective for larger projects where the overhead of detailed modeling pays off through reduced confusion and better coordination.
FDD's focus on features keeps work tied to business value. Rather than organizing around technical tasks or arbitrary sprints, teams constantly ask: "What feature are we delivering?" This orientation helps maintain alignment between technical work and business outcomes.
The five fdd processes
FDD defines five sequential processes:
Develop an Overall Model brings domain experts and developers together to create a high-level object model of the system. This shared understanding prevents the misalignments that plague projects where business and technical teams speak different languages.
Build a Features List breaks the domain into subject areas, which decompose into business activities, which decompose into features. Each feature follows the template: "<action> the <result> <by|for|of|to> a(n) <object>." For example: "Calculate the total for a shopping cart."
Plan by Feature assigns features to development teams and establishes a development schedule. Features are ordered by priority, dependencies, and team capacity. This creates a roadmap that stakeholders can understand.
Design by Feature takes a small group of features and produces detailed design packages. The chief programmer leads this effort, creating sequence diagrams and refining the object model for the features in scope.
Build by Feature implements and tests the designed features. Each feature goes through development, code inspection, and testing before being promoted to the main build.
Feature characteristics
FDD defines features with specific characteristics:
Features that exceed two weeks are broken into smaller features. This constraint ensures regular progress visibility and prevents features from becoming mini-projects.
Roles in fdd
FDD defines several key roles:
Fdd vs. other methodologies
| Aspect | FDD | Scrum | XP |
|---|---|---|---|
| Planning | Feature-based | Sprint-based | Story-based |
| Modeling | Upfront domain model | Emergent | Minimal |
| Iterations | 2 weeks max | 2-4 weeks | 1-2 weeks |
| Roles | Defined hierarchy | Self-organizing | Flat |
| Documentation | Moderate | Minimal | Minimal |
When fdd works well
FDD is particularly suited for:
Challenges
FDD's structure can feel heavy for smaller teams or simpler projects. The upfront modeling phase delays coding, which frustrates teams eager to build. The defined roles may not map well to modern cross-functional team structures.
Like any methodology, FDD works best when adapted to context rather than followed dogmatically. Many teams adopt FDD's feature-centric organization while adjusting other practices to fit their situation.
Tools like Klero complement FDD by connecting features to user feedback. When features emerge from documented user needs rather than assumptions, the features list reflects genuine business value, and teams can track how delivered features impact user satisfaction.
