Skip to content

FDD (Feature-Driven Development)

FDD

Feature-Driven Development

1. Overview of FDD, an Agile Methodology for Large-Scale Projects Built Around Iterative Development by Feature List

    flowchart LR
    A["Large-scale projects are<br/>hard to plan holistically<br/>(uncertain scope & schedule)"] --"Feature-list-based<br/>staged approach"--> B["Iterative development<br/>by Feature, within 2 weeks"] --"Progress visibility<br/>& quality management"--> C["Predictable<br/>large-scale software development"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000
  

Definition: An Agile-based software development methodology proposed by Jeff De Luca that systematically manages large-scale projects through a five-phase process — developing an overall model, building a feature list, planning, designing, and building — centered on a list of Features that customers value.

Characteristics: (Feature) A small unit of functionality expressed in the form “verb + result + object” (e.g., “Look up a customer’s account balance”). (Progress visibility) Iterative development in small Feature units completable within two weeks maximizes progress visibility. (Role structure) A collaborative structure between the Chief Programmer and the Domain Expert.


2. Core Structure of FDD

A. The Five-Phase Development Process

    flowchart LR
    S1["1. Develop Overall Model"]
    S2["2. Build Feature List"]
    S3["3. Plan by Feature"]
    S4["4. Design by Feature"]
    S5["5. Build by Feature"]

    S1 --> S2 --> S3
    S3 --> S4 --> S5
    S5 -->|"Repeat"| S4

    style S1 fill:#E3F2FD,stroke:#1976D2,color:#000
    style S2 fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style S3 fill:#FFF3E0,stroke:#F57C00,color:#000
    style S4 fill:#FFEBEE,stroke:#D32F2F,color:#000
    style S5 fill:#E8F5E9,stroke:#388E3C,color:#000
  
PhaseOwnerKey ActivitiesDeliverables
1. Develop Overall ModelDevelopment team + Domain ExpertRoughly establish the domain model (class diagram) for the entire systemDomain model, class list
2. Build Feature ListChief ProgrammerHierarchically derive a list of Features by business activityFeature list
3. Plan by FeatureDevelopment ManagerEstablish priority, dependencies, and schedule per featureDevelopment plan, progress tracking sheet
4. Design by FeatureChief ProgrammerDetailed design for a selected set of FeaturesSequence diagrams, design packages
5. Build by FeatureClass Owner (developer)Coding, unit testing, code inspection, build, integrationCompleted Features, integration build

B. Feature-Centric Iterative Development Mechanism

    flowchart TD
    subgraph R1[" "]
        direction LR
        F1["Feature hierarchy<br/>Subject Area<br/>→ Business Activity<br/>→ Feature Set<br/>→ Feature"]
        F2["Feature expression format<br/>verb + result + object<br/>e.g., Look up a customer's<br/>order history"]
    end
    subgraph R2[" "]
        direction LR
        F3["Iteration cycle<br/>Design by Feature<br/>Build by Feature<br/>repeats in units of up to 2 weeks"]
        F4["Progress measurement<br/>based on number of<br/>completed Features<br/>tracked weekly, burndown chart"]
    end

    style F1 fill:#E3F2FD,stroke:#1976D2,color:#000
    style F2 fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style F3 fill:#FFF3E0,stroke:#F57C00,color:#000
    style F4 fill:#E8F5E9,stroke:#388E3C,color:#000
    style R1 fill:none,stroke:none
    style R2 fill:none,stroke:none
  

Core FDD Roles

RoleResponsibility
Chief ArchitectDesigns the overall domain model and determines technical direction
Development ManagerManages schedule, resources, and progress
Chief ProgrammerLeads design of a Feature set, conducts code review
Class OwnerResponsible for coding and maintenance of a specific class
Domain ExpertClarifies business requirements and validates the model

Comparison with Scrum and XP

Comparison ItemFDDScrumXP
Iteration unitFeature (within 2 weeks)Sprint (1–4 weeks)Iteration (1–2 weeks)
Planning basisFeature listProduct BacklogUser Story
StrengthLarge-scale projects, progress visibilityFlexible priority adjustmentTechnical quality (TDD, pair programming)
Suitable scaleMedium–large (dozens of people or more)Small–medium (around 10 people)Small (5–10 people)

3. Expected Benefits and Application of FDD

CategoryKey Expected BenefitsApplication and Practical Approach
VisibilityQuantitatively tracks progress by number of completed FeaturesOperate weekly Feature burndown charts for stakeholder reporting
Large-scale applicationApplies Agile practices even in large teams of dozens or moreMaintain design consistency across distributed teams through the Chief Programmer system
Quality managementPerforms code inspection and unit testing at the Feature levelInclude code review in the Definition of Done for feature completion
Domain alignmentEnsures traceability between requirements and code through business-feature-centered developmentCombine with DDD Bounded Contexts to separate Features by domain