Feature-Driven Development (FDD)
A feature is a small, client-valued function expressible in the form: <action> the <result> <by|for|of|to> a(n) <object>.
Feature-Driven Development (FDD) is a model-first, iterative agile methodology that organizes all software work around small, precisely named client-valued features. Developed by Jeff De Luca for large-scale projects, it replaces vague backlog items with rigorously structured feature statements and routes every design, build, and reporting activity through a five-process framework. It is especially suited to teams of 10–50+ developers who need fine-grained progress visibility and clear role accountability.
“We're building a loan origination system for a mid-size bank. We have about 20 developers and a product manager who keeps writing huge epics like…”
Ship client-valued features every two weeks — from domain model to working code
FDD runs through five sequential processes: (1) Develop an Overall Model — domain experts and developers co-build a domain object model using Colored UML; (2) Build a Features List — decompose the model into a three-tier hierarchy of Subject Areas → Business Activities → Features, where each feature follows the strict grammar template and is completable in two weeks or less; (3) Plan by Feature — assign feature sets to Chief Programmers and sequence delivery by dependency and priority; (4) Design by Feature — the Chief Programmer assembles a Feature Team, produces sequence diagrams and a design package; (5) Build by Feature — Class Owners implement their classes, write unit tests, conduct code inspections, and promote the completed feature to the main build. Progress is always reported as a percentage of features complete, giving stakeholders real-time, objective visibility.
Most development teams write requirements as vague, large-scope stories ('Improve the checkout experience') that are impossible to schedule, track, or confidently mark complete. On large teams, this ambiguity compounds: work gets duplicated, ownership is unclear, and progress reports become fiction. FDD directly attacks this by mandating that every piece of work be expressed as a small, client-valued function with a grammatically defined form — nothing enters the build pipeline that doesn't fit in two weeks and can't be objectively verified as done.
Stop estimating and start tracking. After a session with this skill, every requirement your team touches will be reformatted into atomic, client-valued FDD features — each owned by a named developer, scoped to two weeks, and reportable as a binary percentage of work complete.
- A project description, problem statement, or existing requirements document
- An understanding of the business domain or access to domain experts
- Current team size and structure (roles, headcount)
- Any existing backlog items, user stories, or epics to be reformatted
- A properly structured FDD feature list with Subject Areas, Business Activities, and atomic Features using the correct grammar template
- A role assignment map naming Chief Programmers and Class Owners for each feature set
- A feature delivery schedule ordered by dependencies and priorities
- A progress tracking template tied to feature completion percentages, ready for stakeholder reporting
Watch the methodology work.
Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.
“Your product manager's backlog has 12 epics: 'Build loan application flow', 'Set up credit scoring', 'Create document upload system'. Sprint planning takes two hours and still ends without clear assignments. Three developers are working on overlapping parts of the same domain class. The last status report said '40% done' but nobody can say what that means or how you'd get to 100%.”
“The backlog is replaced by an FDD Feature List: 47 features in grammar-correct form, organized under 6 Business Activities within 2 Subject Areas. Each feature is owned by a named Class Owner, supervised by one of 3 Chief Programmers. The progress report shows: 12 features complete (25.5%), 8 in build, 5 in design, 22 not started — every stakeholder reads the same objective number. Sprint planning is a 20-minute feature assignment review.”
The same skill, where the work happens.
No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.
What it does, specifically.
Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.
Feature Grammar Workshop
Takes any requirement — a user story, a vague epic, a stakeholder request — and rewrites it into valid FDD feature statements using the mandatory template: '<action> the <result> <by|for|of|to> a(n) <object>'. Flags overly large or ambiguous statements that would violate the two-week completion rule. Helps teams build the muscle of writing features correctly before they hit planning.
Three-Tier Feature Decomposition
Guides users through decomposing a software domain into the FDD hierarchy: Subject Areas (major functional domains like 'Customer Management'), Business Activities (grouped capabilities within that domain like 'Maintaining Customer Accounts'), and individual Features (atomic two-week deliverables like 'Update the email address for a Customer'). The resulting list becomes the master scope document for the entire project.
Chief Programmer & Class Owner Assignment
Helps project managers and architects map FDD's two critical technical roles to real team members: the Chief Programmer (senior developer who owns a feature set end-to-end, leads its design, and coordinates the Feature Team) and Class Owners (developers responsible for implementing and maintaining specific domain classes). Makes ownership explicit and unambiguous before design work starts.
Feature Schedule Builder
Takes the completed feature list and constructs a delivery sequence based on dependencies, business priorities, and team capacity. Each feature set is assigned to a Chief Programmer with an estimated start and completion window. The output is a schedule that can be updated incrementally as features complete — not a Gantt chart locked to dates, but a priority-ordered feature pipeline.
FDD Progress Report Generator
Produces the FDD-standard progress snapshot: features planned, features in design, features being built, and features complete — each expressed as a percentage of total project scope. Replaces velocity charts and burndown graphs with an objective, feature-centric view that any stakeholder can read without knowing what a 'story point' is.
Graded before it shipped.
Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.
FDD Feature List
A three-tier structured document — Subject Areas at the top, Business Activities in the middle, and atomic Features at the leaf level — every feature written in valid FDD grammar and scoped to two weeks or less. Serves as the master scope and delivery backlog for the project.
Class Ownership Map
A matrix assigning every domain class to a named Class Owner and the Chief Programmer responsible for their feature set. Eliminates ownership ambiguity and makes merge conflicts, design decisions, and accountability chains explicit before build starts.
Feature Delivery Schedule
An ordered table of feature sets with assigned Chief Programmers, priority rankings, dependency notes, and two-week delivery windows. Not a fixed Gantt chart — a living document updated as features complete.
Feature Completion Progress Report
A snapshot report showing features in each FDD pipeline stage (Not Started / In Design / In Build / Complete) as objective percentages of total project scope. Designed for executive and stakeholder reporting — no estimation language, no story points.
Grounded in the original work.
Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.
Jeff De Luca
Jeff De Luca created Feature-Driven Development in 1997 while leading a 50-developer, 15-month banking software project in Singapore — known in the methodology community as 'Project 300'. He developed FDD in collaboration with object-modeling pioneer Peter Coad, and the methodology was formally documented by practitioners Stephen Palmer and Mac Felsing in their 2002 Prentice Hall reference text. De Luca's work established FDD as one of the earliest documented agile methods, predating the Agile Manifesto.
A Practical Guide to Feature-Driven Development (Palmer & Felsing, 2002); FDD Process Documentation by Jeff De Luca
Creator of FDD; led the landmark 50-developer Project 300 banking system in Singapore (1997); co-developed with Peter Coad (inventor of Colored UML / Feature-Driven Object Modeling).
Be first to run it.
Feature-Driven Development (FDD) is being built right now. Leave your email and we’ll tell you the moment it goes live.