1. Feature Driven Design
A whitepaper by John C Goodpasture, PMP
November, 2009
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 1 of 12

2. Feature Driven Design
Feature Driven Design is an agile methodology that centers
attention on small scale requirements—dubbed ‘features’—
that can be rapidly deployed to create customer value.
Everyone can't know everything about everything—that is brittle and it can't scale.
Jeff De Luca
Feature Driven Design, FDD,1 is one of the agile methodologies developed empirically in the late
1990’s. In a word, a feature is a small scale functional need in the general format of
<action><object><result>, like “calculate order total”.2 Jeff De Luca is the acknowledged
inventor of FDD, although De Luca himself credits others with significant contributions—people
like Peter Coad, a well known leader in object oriented [OO] coding, who introduced a prominent
practice to the methodology: fine grain object modeling.3
The founding project was a troubled about the recommended methodology steps
software implementation at a large bank in that FDD can not be applied outside an OO
Singapore in the late 1990’s. De Luca, an implementation. At a high level of
Australian with a proven track record at abstraction, there is nothing that prohibits
IBM, was hired to rescue the project, an taking FDD ideas outside of software.
endeavor that was foundering with
traditional software engineering methods. FDD is designed to be scalable; indeed the
De Luca’s rescue was a medium scale effort first project in Singapore was large by agile
with a few dozen programmers; it lasted for standards. One of De Luca’s scaling points
more than a year.4 is object ownership by individual
developers. Unlike XP, there is not
De Luca organized the project around his collective ownership of development objects
ideas that became known as FDD. He because collective ownership is not scalable
became acquainted with Peter Coad when he in De Luca’s view.6 And another is the
recruited Coad to assist with object emphasis on up-front modeling of the
modeling on the project. In 1999, De Luca, business story or business domain led by an
Coad, and Eric Lefebvre wrote a widely read architect or experienced modeler.
book, “Java Modeling in Color with UML,”
which, among other ideas, described FDD Domain modeling, as it is called in FDD, is
and gave it a public introduction.5 equivalent to architecture commonly
described in the literature. The model is
De Luca et al assume an OO practice intended to show all the major system
framework for FDD; consequently, much of elements and their interaction. De Luca
the jargon that surrounds FDD is from OO; proposes that there be architecture for each
however, there is nothing so fundamental ‘aspect’ of the system, like the presentation
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 2 of 12

3. layer or tier, application layer, data system, descending order: project, aspects, subject
service layers, and so on.7 In some respects, areas, and business activities framed by
De Luca’s ‘aspect’ is much like a ‘view’. milestones to give a temporal dimension.
What you see depends upon your point of
view. The idea that architecture – and a Otherwise, FDD is pretty minimal in its
domain model is architecture – should have, prescription, consisting of five process steps,
or could have different views is accepted a few key players, a minimum set of
doctrine among system architects.8 required responsibilities, a high reliance on
model diagrams to capture requirements,
The ‘core structure’ of the model is loosely and spreadsheet pipelines and status grids to
coupled and hierarchical, as given in visually document project progress.
FDD is very pictorial
• FDD is intended to be scalable
• Although FDD values personal communications
over formal documentation, as do all agile
methods, documentation is valued for its support
for scalability
A Project Management Tip
• FDD values diagrams for domain models, fine
grain object models, and supports a number of
project management scorecards on a project
dashboard and information portal
FDD is defined by its process steps
More so than SCRUM, XP, and Crystal, FDD is known for and characterized by its process steps.
The original definitions of each step were published in “Java Modeling in Color with UML”.
Subsequently, they have been refined with experience; De Luca has documented the updates on
his website.9 Within each step is a somewhat unique mix of conventional practices, although each
practice has been picked for its effectiveness and reinforcement of the process step.
Develop an Overall Model
The first process step is perhaps the most to identify the ‘subject areas’ and ‘business
controversial and the one that separates FDD activities’ that comprise the business story.
from other agile methods: “Develop an De Luca calls this step-one model a ‘model
Overall Model”. In this step, the business shape’; it’s more than a framework because
story, which is called the business domain in the major object classes and their
the FDD literature, is modeled ‘just enough’ interrelationships are defined, but it’s less
than a complete model because all the class
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 3 of 12

4. methods, attributes, and data are not
identified and defined.
The model is generally relational between
For purposes of simple presentation the business steps and classes: one business step
hierarchy for the model for one aspect is feature can require several classes; one class
shown in the panel below. The step-one may support more than one feature. There
model usually goes no farther than are usually many methods within each class.
identifying business activities and the Indeed, moving the feature identification
classes that will be building blocks for and feature lists to step two in the
features. methodology is one of the process
refinements made since 1999. An example is
Model hierarchy given in Table WP1-1:
Business Domain Subject Areas
Business Activities Business Steps
[features] Classes Methods
Table WP1-1 Model Example
Model Level Example
Business Domain In-bound Sales
Subject Area In-bound Orders
Business Activity Order Processing
Business Step [feature] Calculate Order Total
Class [person, place, or
Order Line
thing in the abstract]
Method [behavior or
calculateLineTotal
action]
Various modeling tools such as text, use do its own model; the model results are
cases diagrams, data models, entity- combined in Delphi fashion to reach a
relationship diagrams, user guides, and high- consensus.
level sequence diagrams are applicable.
Critics of the FDD approach liken this
To develop a model, a Delphi-like approach modeling to a ‘big design up front’, BDUF.
is recommended: led by a chief architect or a However, the domain model is not more
chief modeler, the whole team is assembled than the minimally required architecture
and given an explanation of the business needed to frame all subsequent
story—in effect, a domain walkthrough. development.
Smaller multi-functional, business-
developer teams are formed, and each is to
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 4 of 12

5. Build a Features List
The chief programmer, CP, a prominent player in FDD, leads process step 2. In this step, all the
fine grain business steps – that is, features – are identified. No prioritization is made of features;
there are too many: typically hundreds, perhaps thousands, so no prioritization scheme is
meaningful. Table WP1-2 illustrates the FDD feature compared to the use case and user story:
Table WP1-2 Feature Comparison
Fixture Commentary
Specifies actors, initial conditions, triggers, actions, extended
Use Case
actions, included actions, and results.
Actor <name> acting in role <role label> according to action
<action verb> with attributes <skills, security, time of day, etc>
User Story
has expectation <result of action> because <motivation for action,
or reason for storyline, or dependencies or triggers>
FDD Feature <action><object><result>
Plan by Feature
Planning is done for release milestones. Features are assembled into release packages according
to a number of business criteria. The project manager is a key player in the planning, along with
the chief programmer.
Rolling wave planning is applicable. In one class. Collective ownership, an XP
building the release schedule, features must practice, is not allowed because it limits
be sequenced; consideration for customer scale.
importance and urgency, impact on the
benefit stream, impact on market Planning is not time-boxed! Features are
competitiveness, and other business factors, intended to be developed in less than two
as well as technical sequencing go into the weeks duration, however, there is no rigidity
planning. In this step, important ownership around the two week goal—the duration
assignments are made that enable scale. could be much shorter or a little bit longer,
First, business activities are assigned to but not much longer or else the feature
chief programmers as the responsible requires more decomposition. Feature
manager for required development. Second, development duration is further dissected
each class is assigned to a developer as its into six sequential development tasks,
owner. Class ownership does not change beginning with a feature walk-though and
over time; a developer may own more than ending with a promotion to production.10
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 5 of 12

6. Design by Feature:
Borrowing the script from the WBS, features are assembled into work packages led by the CP.
Generally, a work package is the smallest unit identified on a WBS.
A Features Breakdown Structure—FDD’s consisting of the CP and class owners, with
name for the WBS—is built up from all the business user subject matter experts as
work package content. Care is taken to not required. In a stark departure from other
split classes between work packages that are agile methods, feature teams are situational:
simultaneously in development since that they are formed from class owners just in
would split developers between chief time, and then adjourned when the feature is
programmers. production ready. New teams are formed
dynamically around each feature.
Feature teams are formed with
responsibility to own the features—that is, As a construction step, actual design begins
to speak for the required functionality, in this step. The object model and sequence
interpret business needs, and develop the diagrams are refined, and all the object
feature into a product unit. The feature methods are defined, as well as attributes
teams are multi-functional primarily and data requirements.
Build by Feature:
This process step is the second construction inspection. Integration testing of multiple
step; in this step the objects are coded, objects to prove and verify feature
tested, and put into production. In another performance is planned by the chief
departure with other agile methods, and programmer and the developer.
especially XP, code inspections by person-
to-person walk-through are more valued Pair programming is not promoted, but not
than unit tests. That is, even though an prohibited. The material in Table WP1-3
object has passed a unit test it is not sums up the process discussion.
promoted to production until it passes a code
Table WP1-3 Process Summary
FDD Process Step Commentary
Develop an Overall • Equivalent to architecture; identify the essential elements
Model of the system and their interrelationships
• Identify the business steps with business activities;
features are functional and customer-valued.
Build a Features List
• Features are typically designed and built in less than 2
weeks
• Organize sets of features into release packages according
Plan by Features
to technical sequencing constraints and customer priority
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 6 of 12

7. Table WP1-3 Process Summary
FDD Process Step Commentary
• Assign ownership responsibilities
• Organize feature sets into work packages and assign
work packages to chief programmers who are the team
Design by Feature
leads for feature development teams
• Add detail and richness to the fine grain object model
• Code, test, and inspect the product
Build by Feature
• Release product to production
FDD is scalable
• Documentation is valued for scalability
• Class ownership is favored over collective
ownership
A Project Management Tip • The two construction processes are amenable
to fixed price work order contracting
• Rigid time-boxes are not imposed on the
contractor
FDD relies on key practices
In the discussion so far, we’ve spoken to several of the key practices in FDD: domain modeling—
what we call architecture—fine grain object modeling, development by feature, and class
ownership.
Other practices are code inspections, sooner, recovering not only investment but
walkthroughs at every level from domain also adding value to the business.
model to class methods, and dynamic
feature teams. Although not regulated by Of importance to the project manager are the
time-boxes, FDD does promote frequent, scorecards recommended by De Luca and
responsive product delivery, sequenced his disciples. At a high level, each process
according to customer priority, and put into step is gated by the so-called ETVX—
production as determined by business Entry, Task, Verify, and Exit—set of sub-
preparation. Like all agile methods, processes that are scored for completion.
frequent delivery starts the benefit stream There is, of course, a burn-down chart much
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 7 of 12

8. like that in SCRUM and as presented in objects, if not many more, this is a lot of
Appendix I. Scorecards keep up with the six scorekeeping! Table WP1-4 gives a
development stages for each object in each summarization of some of the key practices.
two week iteration; these are called ‘parking
lot charts’. Obviously, with hundreds of
Table WP1-4 FDD Practices
Practice Commentary
• Up-front architecture model of the system, its
aspects, and the business activities
Domain Model
• Later refined to include classes and feature [sets of
classes with a business relationship]
• Peer review of models and design to achieve
Walkthrough
understanding and catch logical and functional holes
Inspection • Peer review of developer deliverables
• Developer assignment for design and development of
a class
Class ownership
• Ownership is not changed during the course of the
project
• Set of classes to be developed into features in one
Work package
iteration; assigned to a chief programmer
• Graphical or spreadsheet portrayal of object and
Scorecard
release status
• Teams formed for the duration of an iteration to
Feature Teams
deliver work packages
• Production of work packages every two weeks, or
Frequent release
sooner
• Technique for independent thinkers to arrive at a
Delphi
consensus
Summary and take-away points
• Our theme is that Feature Driven Design is an agile methodology that centers attention on
small scale requirements dubbed ‘features’ that can be rapidly deployed to create customer
value.
• There are five process steps that lead from a top-level model of the business story to the
production deployment of packages of features. There are several key practices that make
FDD work; for the most part, these practices are not new in the software industry. What is
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 8 of 12

9. unique is how the practices are used to support each of the five processes.
• However, several practices common to other agile methods are missing: time-boxing, pair
programming, collective object ownership, and user stories to name the most visible.
• FDD is designed to be a scalable methodology although its focus on snips of functionality —
that is to say, features—challenges cohesiveness in the larger picture. Documentation
sufficient to support architecture and planning is valued for its support for scale.
• Overall, FDD is a respected member of the agile family of methodologies with a track record
extending back to the late 1990’s.
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 9 of 12

10. Endnotes
1 Feature Driven Development, FDD, FDDI, and the FDD logo, are trademarks of Nebulon Pty.
Ltd. FDDI is FDD Interchange, a library of tools and specifications
2 See Palmer, S. and Felsing, J. “A Practical Guide to Feature Driven Design” Prentice-Hall,
Upper Saddle River, NJ, 2002, pg 46.
De Luca actually defines two feature formats: one identical to Palmer’s definition and one that is
slightly more complex: <action> the <result> <by|for|of|to> a(n) <object> as given in “Feature
Driven Development Overview”, Nebulon.com, 2005,
http://nebulon.com/articles/fdd/fddoverpres.html, retrieved August 2009
3 Interview with Jeff De Luca:
Roock, S. “Jeff De Luca on Feature Driven Development” http://www.it-
agile.com/fileadmin/docs/FDD-Interview_en_final.pdf, April 2007, retrieved August 2009
Other contributors: Stephen Palmer, editor of the COAD Letter, M. A. Rajashima who inspired
the ETVX – entry, task, verify, exit – gates of the process steps, and Lim Bak Wee, Paul Szego,
and Jon Kern. See: http://www.informit.com/articles/article.aspx?p=26055&seqNum=7,
retrieved August 2009
4 See a short history in Jim Highsmith’s article in Crosstalk:
Highsmith, J. “What is Agile Development?” Crosstalk, the Journal of Defense Software
Engineering, October, 2002,
http://www.stsc.hill.af.mil/crosstalk/2002/10/highsmith.html, retrieved August, 2009
5 De Luca, J., Coad, P., and Lefebvre, E. “Java Modeling in Color with UML – Enterprise
Components and Process” Prentice-Hall, Upper Saddle River, NJ, 1999, Chapter 6
6 Interview with Jeff De Luca:
Roock, S. “Jeff De Luca on Feature Driven Development” http://www.it-
agile.com/fileadmin/docs/FDD-Interview_en_final.pdf, April 2007, retrieved August 2009
7 Editor, “FDD Interchange Specification 20060119”, Nebulon Pty, Ltd, January 19, 2006
8 See IEEE 1471:2000 “IEEE Recommended Practice for Architectural Description of Software-
Intensive Systems” IEEE, March 2006, Chapter 5.4
Also known as ISO/IEC 42010:2007, “Recommended Practice for Architectural Description of
Software-Intensive Systems” July 2007.
9 The latest FDD processes are documented at http://nebulon.com/articles/fdd/latestfdd.html,
retrieved August, 2009
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 10 of 12

11. 10 See “Feature Driven Development Overview”, Nebulon.com, 2005, pg 13,
http://nebulon.com/articles/fdd/fddoverpres.html, retrieved August 2009
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 11 of 12

12. About the author
John C. Goodpasture, PMP and managing principal at Square Peg Consulting, is a program
manager, coach, author, and project consultant specializing in technology projects, strategic
planning, project office operations. He is the author of books, articles, and web logs in the field
of project management. He blogs at johngoodpasture.com, provides presentations at
www.slideshare.com/jgoodpas, and his work products are found in the library at www.
sqpegconsulting.com.
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 12 of 12