fdd-guide

name

fdd-guide

description

Use when running Feature-Driven Development's process scaffolding — the five processes (Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature, Build by Feature), naming features with the action-result-object template, decomposing into feature sets and major feature sets, tracking the six weighted build milestones, and organising Chief Architect / Chief Programmer / Class Owner roles and per-feature-set teams. Triggers on FDD, feature-driven development, feature list, design by feature, build by feature, feature-naming template, milestone percent-complete, class owner, chief programmer — even when the user doesn't say 'FDD'.

Feature-Driven Development

FDD is a model-driven, short-iteration delivery rhythm built from five processes, a strict feature-naming template, a feature-set hierarchy, and six weighted milestones that report exact percent-complete per feature. It owns the choreography and tracking; the domain model and the notion of client value are owned elsewhere.

Essentials

• Run the five processes in order - Develop an Overall Model, Build a Features List, Plan by Feature, then iterate Design by Feature and Build by Feature, see references/fdd-processes.md
• Name every feature <action> the <result> by/for/of/to a(n) <object> - the connector is any of by/for/of/to, see references/fdd-processes.md
• Decompose features into feature sets into major feature sets - features group by business activity, feature sets group into subject areas, see references/fdd-processes.md
• Size each feature at two weeks maximum - most take 1-3 days; split any business step larger than two weeks, see references/fdd-processes.md
• Track build with six weighted milestones summing to 100% - 1/40/3/45/10/1 from walkthrough to promote, see references/fdd-processes.md
• Staff per-feature-set teams under one Chief Programmer with per-class Class Owners - feature teams form dynamically, see references/fdd-processes.md

Gotchas

• The two-week limit is a feature's MAX SIZE, not a Scrum-style sprint timebox — FDD predates and does not use sprints; most features take 1-3 days.
• The feature template connector is by/for/of/to, not always "of"; writing only <action> the <result> of a(n) <object> narrows the pattern.
• Process 1 (Develop an Overall Model) is domain modelling owned by ddd-guide — FDD contributes the process placement, not a new modelling theory.
• A "feature team" is not a "feature" and is not a named role — it is a transient team formed per feature set under a Chief Programmer.
• The six milestone weights are exact (Code 45% and Design 40% dominate); an even split is folklore. They sum to 100%.
• FDD uses single-owner-per-class (Class Owner) and design/code inspections — it is not interchangeable with collective code ownership or XP/Scrum practices.

Example

Major feature set: Order Management
  Feature set: Processing an order
    Feature: Calculate the total of an order
    Feature: Apply the discount to an order
    Feature: Validate the shipping address of an order
    Feature: Reserve the inventory for an order line
    Feature: Authorize the payment for an order        <- in build
        Domain Walkthrough  1%   [x]
        Design             40%   [x]
        Design Inspection   3%   [x]
        Code               45%   [ ]   <- 44% complete
        Code Inspection    10%   [ ]
        Promote to Build    1%   [ ]

Progressive Disclosure

• Read references/fdd-processes.md - Load when running the five processes, naming features, sizing/decomposing the feature list, tracking the six milestones, or staffing roles and feature teams