Feature-Driven Development (FDD)

Complete guide to Feature-Driven Development (FDD): an iterative and incremental software development methodology that delivers features incrementally with clear ownership. Learn how FDD organizes development around features, promotes model-driven design, and ensures regular delivery of working software.

Table of Contents

1. What is Feature-Driven Development?

Feature-Driven Development (FDD) is an iterative and incremental software development methodology created by Jeff De Luca and Peter Coad. FDD organizes software development around features—client-valued functionality that can be implemented in two weeks or less.

FDD combines the best practices from other methodologies, emphasizing:

  • Model-driven design: Building a comprehensive object model before coding
  • Feature-centric development: Organizing work around small, client-valued features
  • Individual ownership: Assigning features to individual developers or small teams
  • Regular builds: Frequent integration and builds to ensure continuous progress
  • Progress tracking: Regular reporting on feature completion

FDD is particularly well-suited for larger teams and projects where clear organization and ownership are important. It provides structure while maintaining agility and focus on delivering value.

2. Why Use FDD?

  • Clear organization: FDD provides a clear structure for organizing work, making it easier to manage large projects.
  • Regular delivery: Features are delivered incrementally, providing regular value to stakeholders.
  • Clear ownership: Each feature has a clear owner, reducing confusion and improving accountability.
  • Scalability: FDD works well for larger teams and projects where coordination is important.
  • Progress visibility: Regular reporting makes progress visible to all stakeholders.
  • Model-driven approach: Building a comprehensive model upfront helps identify issues early.
  • Feature focus: Organizing around features keeps the team focused on delivering value.

3. The FDD Process

FDD consists of five main processes that are executed iteratively:

graph TB A[1. Develop Overall Model
Domain Modeling] --> B[2. Build Feature List
Feature Identification] B --> C[3. Plan by Feature
Feature Planning] C --> D[4. Design by Feature
Feature Design] D --> E[5. Build by Feature
Feature Implementation] E --> C style A fill:#e1f5ff,stroke:#0273bd,stroke-width:2px style B fill:#fff4e1,stroke:#f57c00,stroke-width:2px style C fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style D fill:#fce4ec,stroke:#2e7d32,stroke-width:2px style E fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px

3.1 Develop Overall Model

The team, including domain experts, creates an overall object model of the system. This involves:

  • Domain walkthroughs with domain experts
  • Creating class diagrams and sequence diagrams
  • Identifying major classes and their relationships
  • Building a shared understanding of the domain

This process is iterative and continues throughout the project as understanding deepens.

3.2 Build Feature List

Features are identified and organized into a feature list. A feature in FDD is:

  • Client-valued functionality
  • Small enough to be completed in two weeks
  • Expressed in the form: "<action> <result> <object>"

Examples:

  • "Calculate total price for order"
  • "Display user profile information"
  • "Send order confirmation email"

3.3 Plan by Feature

Features are assigned to developers (feature owners) and planned. This involves:

  • Prioritizing features
  • Assigning features to developers
  • Estimating effort
  • Creating a development schedule

3.4 Design by Feature

For each feature, a detailed design is created:

  • Class diagrams showing classes involved
  • Sequence diagrams showing interactions
  • Design walkthroughs with the team
  • Design inspection and approval

3.5 Build by Feature

Features are implemented following the design:

  • Code implementation
  • Unit testing
  • Code inspection
  • Integration into the main build

Once a feature is complete, it's integrated and the process repeats for the next feature.

4. Key Concepts

4.1 Features

A feature in FDD is a small, client-valued piece of functionality that can be implemented in two weeks or less. Features are expressed in the form: 

<action> <result> <object>

Examples:

  • "Calculate total price for order"
  • "Validate email address for user"
  • "Generate invoice PDF for order"
  • "Send notification email to customer"

4.2 Feature Sets

Related features are grouped into feature sets, which represent major areas of functionality. For example:

  • User Management:
    • Register new user
    • Login user
    • Update user profile
    • Reset user password
  • Order Processing:
    • Create order
    • Add item to order
    • Calculate order total
    • Process order payment

4.3 Feature Owner

Each feature has a feature owner—a developer responsible for implementing that feature. The feature owner:

  • Designs the feature
  • Implements the feature
  • Tests the feature
  • Integrates the feature

4.4 Chief Programmer

The Chief Programmer is an experienced developer who:

  • Leads the overall modeling effort
  • Coordinates feature development
  • Conducts design and code inspections
  • Mentors other developers

4.5 Class Owner

A Class Owner is responsible for a specific class or set of classes. They:

  • Maintain the class design
  • Review changes to the class
  • Ensure class quality and consistency

5. Defining Features

Good features in FDD have specific characteristics:

5.1 Feature Characteristics

  • Client-valued: Provides value to the end user or client
  • Small: Can be completed in two weeks or less
  • Testable: Can be verified to work correctly
  • Independent: Can be developed relatively independently
  • Well-defined: Clear what needs to be done

5.2 Feature Template

Feature: <action> <result> <object>

Description: Brief description of what the feature does

Owner: [Developer name]

Dependencies: [List of features this depends on]

Design:
  - Classes involved: [List of classes]
  - Sequence: [Brief description of sequence]
  - Diagrams: [References to design diagrams]

Acceptance Criteria:
  - [Criterion 1]
  - [Criterion 2]
  - [Criterion 3]

Estimated Effort: [Hours or days]

5.3 Example Feature Definition

Feature: Calculate total price for order

Description: Calculate the total price of an order including 
items, taxes, and shipping costs.

Owner: John Developer

Dependencies: 
  - Add item to order
  - Calculate tax for order

Design:
  Classes involved:
    - Order
    - OrderItem
    - TaxCalculator
    - ShippingCalculator
  
  Sequence:
    1. Order retrieves all OrderItems
    2. Calculate subtotal from items
    3. Calculate tax using TaxCalculator
    4. Calculate shipping using ShippingCalculator
    5. Sum subtotal + tax + shipping
    6. Return total

Acceptance Criteria:
  - Total includes sum of all item prices
  - Total includes applicable taxes
  - Total includes shipping costs
  - Total is calculated correctly for empty orders (returns 0)
  - Total handles discounts correctly

Estimated Effort: 3 days

6. Practical Examples

6.1 E-Commerce System: Feature List

Feature Set: User Management
  - Register new user
  - Login user
  - Logout user
  - Update user profile
  - Reset user password
  - Delete user account

Feature Set: Product Catalog
  - Display product list
  - Display product details
  - Search products
  - Filter products by category
  - Sort products by price

Feature Set: Shopping Cart
  - Add item to cart
  - Remove item from cart
  - Update item quantity
  - Calculate cart total
  - Clear cart
  - Display cart contents

Feature Set: Order Processing
  - Create order from cart
  - Calculate order total
  - Apply discount code
  - Process payment
  - Generate order confirmation
  - Send order confirmation email
  - Track order status

6.2 Feature Implementation Example

Let's see how a feature is implemented following FDD:

Feature: Calculate total price for order

Step 1: Design

// Class diagram
Order
  - orderId: OrderId
  - items: List<OrderItem>
  - status: OrderStatus
  + calculateTotal(): Money

OrderItem
  - productId: ProductId
  - quantity: Quantity
  - unitPrice: Money
  + getSubtotal(): Money

TaxCalculator
  + calculateTax(subtotal: Money, address: Address): Money

ShippingCalculator
  + calculateShipping(items: List<OrderItem>, address: Address): Money

// Sequence diagram
Order.calculateTotal()
  1. Get all OrderItems
  2. Calculate subtotal (sum of OrderItem.getSubtotal())
  3. Calculate tax (TaxCalculator.calculateTax())
  4. Calculate shipping (ShippingCalculator.calculateShipping())
  5. Return subtotal + tax + shipping

Step 2: Implementation

public class Order {
    private OrderId orderId;
    private List<OrderItem> items;
    private OrderStatus status;
    private TaxCalculator taxCalculator;
    private ShippingCalculator shippingCalculator;
    
    public Money calculateTotal() {
        // Calculate subtotal
        Money subtotal = items.stream()
            .map(OrderItem::getSubtotal)
            .reduce(Money.ZERO, Money::add);
        
        // Calculate tax
        Money tax = taxCalculator.calculateTax(subtotal, getShippingAddress());
        
        // Calculate shipping
        Money shipping = shippingCalculator.calculateShipping(items, getShippingAddress());
        
        // Return total
        return subtotal.add(tax).add(shipping);
    }
}

public class OrderItem {
    private ProductId productId;
    private Quantity quantity;
    private Money unitPrice;
    
    public Money getSubtotal() {
        return unitPrice.multiply(quantity.getValue());
    }
}

Step 3: Testing

@Test
public void shouldCalculateTotalWithTaxAndShipping() {
    // Arrange
    Order order = new Order();
    order.addItem(new OrderItem(product1, quantity(2), money(100)));
    order.addItem(new OrderItem(product2, quantity(1), money(50)));
    
    // Act
    Money total = order.calculateTotal();
    
    // Assert
    Money expectedSubtotal = money(250);
    Money expectedTax = money(25); // 10% tax
    Money expectedShipping = money(10);
    Money expectedTotal = money(285);
    
    assertEquals(expectedTotal, total);
}

6.3 Feature Tracking

FDD emphasizes tracking feature progress. A typical feature tracking table:

Feature Owner Status Progress
Calculate total price for order John In Progress 60%
Add item to cart Jane Complete 100%
Process payment Bob Design 30%

7. FDD Roles and Responsibilities

7.1 Chief Architect

The Chief Architect is responsible for:

  • Leading the overall modeling effort
  • Ensuring architectural consistency
  • Making key design decisions
  • Mentoring developers

7.2 Chief Programmer

The Chief Programmer (may be the same as Chief Architect) is responsible for:

  • Coordinating feature development
  • Conducting design and code inspections
  • Assigning features to developers
  • Tracking progress

7.3 Feature Owner

A Feature Owner (developer) is responsible for:

  • Designing their assigned feature
  • Implementing the feature
  • Testing the feature
  • Integrating the feature

7.4 Class Owner

A Class Owner is responsible for:

  • Maintaining specific classes
  • Reviewing changes to their classes
  • Ensuring class quality

7.5 Domain Expert

Domain Experts provide:

  • Business knowledge
  • Domain insights
  • Requirements clarification
  • Validation of the model

8. Best Practices

8.1 Keep Features Small

Features should be completable in two weeks or less. If a feature is too large, break it into smaller features.

8.2 Maintain the Model

Keep the overall model up-to-date as the system evolves. The model is a living document that reflects the current understanding of the system.

8.3 Regular Builds

Integrate features frequently. Regular builds ensure that features work together and problems are caught early.

8.4 Code Inspections

Conduct code inspections to ensure quality and share knowledge. Inspections help catch defects early and improve code quality.

8.5 Clear Ownership

Ensure each feature has a clear owner. This improves accountability and reduces confusion about who is responsible for what.

8.6 Progress Reporting

Report progress regularly. Use feature completion percentages and feature lists to track progress and communicate status.

8.7 Design Before Coding

Complete the design before starting implementation. Good design reduces rework and improves code quality.

8.8 Feature Dependencies

Manage feature dependencies carefully. Plan features so that dependencies are implemented first.

9. FDD vs Other Methodologies

9.1 FDD vs Scrum

Aspect FDD Scrum
Focus Features User stories
Ownership Individual feature owners Team ownership
Modeling Comprehensive upfront modeling Just-in-time design
Team Size Works well for larger teams Small to medium teams

9.2 FDD vs XP (Extreme Programming)

FDD is more structured and model-driven, while XP emphasizes simplicity and just-in-time design. FDD works better for larger teams, while XP is suited for smaller, co-located teams.

9.3 When to Use FDD

FDD is particularly suitable when:

  • Working with larger teams (10+ developers)
  • Need for clear organization and ownership
  • Complex domain requiring upfront modeling
  • Need for regular progress reporting
  • Distributed teams requiring clear coordination

    • 9.4 Combining Methodologies

    Many teams combine FDD with other methodologies:

    • FDD + Scrum: Use FDD's feature-centric approach within Scrum sprints
    • FDD + TDD: Use TDD for implementation while FDD organizes the work
    • FDD + BDD: Use BDD for feature specifications within FDD's feature structure

10. Conclusion

Feature-Driven Development provides a structured approach to software development that organizes work around client-valued features. By emphasizing model-driven design, clear ownership, and regular delivery, FDD helps teams deliver software incrementally while maintaining quality and organization.

The key to successful FDD is maintaining the balance between upfront modeling and iterative development. While FDD emphasizes building a comprehensive model, it also recognizes that understanding evolves and the model should be refined continuously. Features provide a natural unit of work that keeps teams focused on delivering value.

FDD is particularly valuable for larger teams and projects where organization and coordination are important. By assigning clear ownership to features and maintaining regular progress reporting, FDD helps teams stay organized and deliver consistently. Whether used alone or combined with other methodologies, FDD provides a solid foundation for feature-centric development.

Tags:

Post a Comment

0 Comments