Feature-Driven Development (FDD)
Feature-centric delivery with regular tangible results
Feature-Driven Development (FDD) organises development around a list of client-valued features, delivered in short iterations (typically 1–2 weeks per feature). Unlike Scrum, FDD has distinct up-front modelling and planning phases that create a domain model and feature list before iterative delivery begins. It scales to large teams (50–300) better than most agile methods.
Developed by Jeff De Luca and Peter Coad for a 15-month, 50-person banking project in Singapore in 1997. Documented in "A Practical Guide to Feature-Driven Development" (2002).
Use Feature-Driven Development (FDD) when
- ✓Large teams (20–300 developers) that need structured coordination without SAFe's overhead
- ✓Domain-complex projects where an initial domain model prevents later rework
- ✓Organisations that need a feature-centric progress report ("X of Y features complete")
- ✓Teams transitioning from waterfall who need more structure than Scrum provides
Avoid it when
- ✗Small teams (< 10) where FDD's modelling phases add overhead without benefit
- ✗Early-stage products where the domain is not yet understood well enough to model
- ✗Projects where continuous customer collaboration can substitute for upfront design
Key Concepts
A small, client-valued function in the format: "<action> the <result> <by|for|of|to> a(n) <object>". E.g. "Calculate the total of a shopping cart."
A high-level class diagram built collaboratively in phase 2. Provides shared vocabulary and design foundation.
A hierarchical list: subject areas → business activities → features. All features must be deliverable in < 2 weeks.
A senior developer who owns a set of features, coordinates design, and guides less experienced developers.
Every class in the domain model is owned by one developer who controls changes to it.
A temporary, dynamically formed team of class owners assembled for a specific feature set.
How it works
Domain experts and developers build a high-level domain object model in 1–2 weeks. Creates shared language.
Decompose domain into subject areas, business activities, and features. Every feature is < 2 weeks of work.
Sequence features into a delivery plan. Assign feature sets to chief programmers and classes to class owners.
Chief programmer leads design of a small feature set. Produces a design package reviewed by peers.
Feature teams implement, unit test, and integrate. Feature is complete when it passes an inspection.
Tools that support Feature-Driven Development (FDD)
Industry standard for software development teams — most PMs will encounter Jira in their career
Exceptionally intuitive and visually clean interface — one of the lowest onboarding friction tools for non-technical teams
Highly visual and intuitive interface with color-coded boards — one of the easiest PM tools for non-technical teams to adopt
All-in-one platform replacing multiple tools — docs, whiteboards, goals, time tracking, chat, and project management in a single workspace
Unmatched flexibility as an all-in-one workspace — combines docs, wikis, databases, and project management in a single tool
Browser-based with no installation required — runs on any OS and enables instant sharing via URL, removing friction for cross-functional collaboration with PMs, engineers, and stakeholders
Best-in-class infinite canvas experience — the gold standard for collaborative whiteboarding with real-time multiplayer editing
De facto standard for workplace communication — most PMs will use Slack daily, and it appears constantly in job descriptions
Frequently Asked Questions
FDD has explicit up-front modelling and planning phases that Scrum lacks. FDD is more prescriptive about roles (chief programmers, class owners) and organises work around features in a fixed hierarchy. Scrum is more flexible but gives less guidance on design-level coordination.
FDD uses UML-like class diagrams for domain modelling, but strict UML compliance isn't required. The goal is a shared visual model that the whole team understands. Simplified domain diagrams work fine for most teams.
FDD is less prominent than Scrum but remains in use in large-scale financial services and enterprise software projects where its structured approach to domain modelling and class ownership proves valuable. Many of its concepts (feature-centric delivery, chief programmer roles) influenced later methodologies.