{
  "id": "page:library-feature-driven-development",
  "_kind": "Page",
  "_file": "wiki/library/feature-driven-development.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "title": "Feature-Driven Development (FDD) (Library)",
    "displayName": "Feature-Driven Development (FDD) (Library)",
    "slug": "library/feature-driven-development",
    "articlePath": "wiki/library/feature-driven-development.md",
    "article": "\n# Feature-Driven Development (FDD)\n\n**Creator**: Jeff De Luca and Peter Coad\n**Year**: 1997\n**Category**: Feature-Centric Agile / Progress Tracking\n**Priority**: High\n\n## Overview\n\nFeature-Driven Development (FDD) is an agile methodology that organizes software development around building small, client-valued features in short, predictable cycles. Created during a massive Singapore banking project with 50+ developers, FDD combines the discipline needed for large-scale projects with agile responsiveness.\n\nFDD is particularly well-suited for:\n- **Large teams** (15-500+ developers)\n- **Enterprise projects** requiring rigorous tracking\n- **Client-facing applications** with clearly defined features\n- **Projects requiring high visibility** of progress\n- **Brownfield development** with existing codebases\n\n## Key Principles\n\n### Five-Step Process\n\n1. **Develop Overall Model** - Domain walkthrough and object modeling\n2. **Build Features List** - Feature decomposition in `<action> <result> <object>` format\n3. **Plan by Feature** - Sequencing, Chief Programmer assignment, iteration scheduling\n4. **Design by Feature** - Detailed design with sequence diagrams and design inspection\n5. **Build by Feature** - Implementation, testing, code inspection, integration, promotion\n\n### Core Characteristics\n\n- **Parking Lot Diagrams**: Visual progress tracking with colored feature set boxes\n- **Class Ownership**: Individual developers own classes (reduces merge conflicts)\n- **Feature Teams**: Chief Programmer + 2-5 developers per team\n- **Regular Builds**: 2-week iterations with working builds\n- **Client-Valued Features**: Everything organized around delivering business value\n- **Inspections**: Design and code inspections ensure quality\n\n### Feature Format\n\nFDD features follow a strict template:\n\n```\n<action> <result> <object>\n```\n\n**Examples**:\n- Calculate total of sale\n- Validate password of user\n- Display history of account\n- Generate report of transactions\n- Update status of order\n\nFeatures should be small enough to implement in 2 hours to 2 weeks.\n\n## Usage\n\n### Basic Usage\n\n```javascript\nimport { babysit } from '@a5c-ai/babysitter-sdk';\n\nconst result = await babysit({\n  process: 'methodologies/feature-driven-development',\n  inputs: {\n    projectName: 'E-Commerce Platform',\n    domainDescription: 'Online retail system with shopping cart, payment, and order management',\n    iterationWeeks: 2,\n    teamSize: 12,\n    chiefProgrammers: 3\n  }\n});\n```\n\n### With Predefined Features\n\n```javascript\nconst result = await babysit({\n  process: 'methodologies/feature-driven-development',\n  inputs: {\n    projectName: 'Banking System',\n    domainDescription: 'Core banking with accounts, transactions, and reporting',\n    features: [\n      {\n        id: 'f-001',\n        title: 'Calculate interest of account',\n        action: 'Calculate',\n        result: 'interest',\n        object: 'account',\n        priority: 'high',\n        estimatedDays: 3\n      },\n      {\n        id: 'f-002',\n        title: 'Validate balance of transaction',\n        action: 'Validate',\n        result: 'balance',\n        object: 'transaction',\n        priority: 'high',\n        estimatedDays: 2\n      }\n    ],\n    iterationWeeks: 2\n  }\n});\n```\n\n### Brownfield Project\n\n```javascript\nconst result = await babysit({\n  process: 'methodologies/feature-driven-development',\n  inputs: {\n    projectName: 'Legacy Modernization',\n    domainDescription: 'Modernize order management system',\n    existingCodebase: {\n      structure: 'Monolithic Java application',\n      mainPackages: ['com.company.orders', 'com.company.customers'],\n      database: 'Oracle 11g',\n      frameworks: ['Spring', 'Hibernate']\n    },\n    iterationWeeks: 2,\n    teamSize: 8,\n    chiefProgrammers: 2\n  }\n});\n```\n\n## Input Schema\n\n```typescript\ninterface FDDInputs {\n  // Required\n  projectName: string;              // Project name\n  domainDescription: string;        // High-level business domain description\n\n  // Optional\n  iterationWeeks?: number;          // Default: 2\n  features?: Array<Feature>;        // Pre-defined features (will generate if not provided)\n  existingCodebase?: Object;        // For brownfield projects\n  teamSize?: number;                // Default: 6\n  chiefProgrammers?: number;        // Default: 2\n}\n\ninterface Feature {\n  id: string;\n  title: string;                    // In <action> <result> <object> format\n  action: string;\n  result: string;\n  object: string;\n  priority: 'high' | 'medium' | 'low';\n  estimatedDays: number;\n  dependencies?: string[];          // IDs of dependent features\n}\n```\n\n## Output Schema\n\n```typescript\ninterface FDDOutput {\n  success: boolean;\n  projectName: string;\n\n  // Step 1: Domain Model\n  domainModel: {\n    classes: Array<{\n      name: string;\n      responsibilities: string;\n      attributes: string[];\n      methods: string[];\n      stereotype: string;\n    }>;\n    relationships: Array<{\n      from: string;\n      to: string;\n      type: string;\n      description: string;\n    }>;\n    modelDiagram: string;\n  };\n\n  // Step 2: Features List\n  featuresList: {\n    featureSets: Array<{\n      id: string;\n      name: string;\n      description: string;\n      features: Feature[];\n    }>;\n    totalFeatures: number;\n    parkingLotLayout: string;\n  };\n\n  // Step 3: Plan\n  plan: {\n    iterations: Array<{\n      number: number;\n      features: Feature[];\n      chiefProgrammerAssignments: Array<{\n        chiefProgrammer: string;\n        features: string[];\n        classOwners: string[];\n      }>;\n    }>;\n    classOwnership: Record<string, string>;\n    schedule: {\n      totalWeeks: number;\n      iterationCount: number;\n      startDate: string;\n      estimatedEndDate: string;\n    };\n  };\n\n  // Steps 4 & 5: Iterations\n  iterations: Array<{\n    iterationNumber: number;\n    features: Feature[];\n    results: Array<{\n      chiefProgrammer: string;\n      features: Array<{\n        feature: Feature;\n        design: DesignResult;\n        build: BuildResult;\n      }>;\n    }>;\n    parkingLot: ParkingLotResult;\n    metrics: {\n      totalFeatures: number;\n      completedFeatures: number;\n      completionRate: number;\n    };\n  }>;\n\n  // Final Parking Lot\n  parkingLot: {\n    svgContent: string;\n    completionPercentage: number;\n    featureSetStatus: Array<{\n      name: string;\n      completed: number;\n      total: number;\n      percentage: number;\n      color: string;\n    }>;\n  };\n\n  // Metrics\n  metrics: {\n    totalFeatures: number;\n    completedFeatures: number;\n    completionRate: number;\n    totalIterations: number;\n    averageFeaturesPerIteration: number;\n    featureSetCompletion: Array<{\n      name: string;\n      total: number;\n      completed: number;\n      percentage: number;\n    }>;\n  };\n}\n```\n\n## Process Workflow\n\n### Step 1: Develop Overall Model\n\n**Duration**: 1-3 days for medium projects\n\n- Domain walkthrough with business experts\n- Study existing requirements and documentation\n- Identify major domain objects and entities\n- Define classes with responsibilities, attributes, and methods\n- Map relationships (associations, inheritance, composition)\n- Create UML class diagrams\n- Identify bounded contexts\n\n**Artifacts**:\n- `artifacts/fdd/domain-model.md` - Human-readable model\n- `artifacts/fdd/domain-model.json` - Machine-readable structure\n\n### Step 2: Build Features List\n\n**Duration**: 1-2 days\n\n- Identify major feature sets (functional areas)\n- Decompose into individual features using `<action> <result> <object>` format\n- Prioritize features by business value\n- Identify dependencies\n- Organize into parking lot structure\n- Map features to domain classes\n\n**Artifacts**:\n- `artifacts/fdd/features-list.md` - Organized feature list\n- `artifacts/fdd/features-list.json` - Structured feature data\n\n### Step 3: Plan by Feature\n\n**Duration**: 1 day\n\n- Sequence features based on dependencies\n- Assign features to Chief Programmers\n- Identify class owners (individual ownership)\n- Organize into 2-week iterations\n- Balance workload across teams\n- Generate initial parking lot diagram\n\n**Artifacts**:\n- `artifacts/fdd/feature-plan.md` - Detailed plan\n- `artifacts/fdd/feature-plan.json` - Plan data\n- `artifacts/fdd/parking-lot-initial.svg` - Initial progress visualization\n\n### Step 4: Design by Feature\n\n**Duration**: 1 day or less per feature\n\nFor each feature:\n- Refine domain model\n- Create sequence diagrams\n- Design class methods and interfaces\n- Identify algorithms and patterns\n- Perform design inspection (peer review)\n- Document design decisions\n\n**Artifacts**:\n- `artifacts/fdd/designs/{feature-id}-design.md` - Design documentation per feature\n\n### Step 5: Build by Feature\n\n**Duration**: 2 hours to 2 weeks per feature\n\nFor each feature:\n- Implement code following design\n- Respect class ownership\n- Write unit tests\n- Perform code inspection\n- Run all tests\n- Integrate with main build\n- Promote to build (mark complete)\n\n**Artifacts**:\n- `artifacts/fdd/builds/{feature-id}-build.md` - Build report per feature\n\n### Parking Lot Diagram\n\nGenerated at each iteration showing:\n- Feature sets as colored boxes\n- Completion percentage per set\n- Overall project progress\n\n**Color Coding**:\n- 🟢 **Green** (100%): Complete\n- 🟡 **Yellow** (50-99%): In progress (majority done)\n- 🔴 **Red** (1-49%): In progress (early stage)\n- ⚪ **Gray** (0%): Not started\n\n## Examples\n\nSee the `examples/` directory for:\n- `e-commerce.json` - E-commerce platform with shopping cart\n- `banking.json` - Core banking system\n- `healthcare.json` - Patient management system\n- `brownfield.json` - Legacy modernization project\n\n## Integration with Other Methodologies\n\n### FDD + Spec-Kit\n\nUse Spec-Kit's constitution and specification phases, then apply FDD for implementation:\n\n```javascript\n// 1. Run Spec-Kit for requirements\nconst specResult = await babysit({\n  process: 'methodologies/spec-driven-development',\n  inputs: { projectName: 'Banking System', /* ... */ }\n});\n\n// 2. Use FDD for feature-driven implementation\nconst fddResult = await babysit({\n  process: 'methodologies/feature-driven-development',\n  inputs: {\n    projectName: 'Banking System',\n    domainDescription: specResult.specification.summary,\n    features: convertUserStoriesToFeatures(specResult.specification.userStories)\n  }\n});\n```\n\n### FDD + DDD\n\nUse Domain-Driven Design for \"Develop Overall Model\" phase:\n\n```javascript\n// Deep domain modeling with DDD, then FDD for delivery\nconst dddModel = await babysit({\n  process: 'methodologies/domain-driven-design',\n  inputs: { /* ... */ }\n});\n\nconst fddResult = await babysit({\n  process: 'methodologies/feature-driven-development',\n  inputs: {\n    projectName: 'Complex Domain',\n    domainDescription: dddModel.description,\n    // Use DDD model as input\n  }\n});\n```\n\n### FDD + Agile\n\nFDD naturally integrates with Scrum:\n- FDD iterations = Sprints\n- Chief Programmers = Senior developers\n- Feature sets = Epics\n- Features = User stories\n\n## Best Practices\n\n### 1. Keep Features Small\n\nFeatures should be completable in 2 hours to 2 weeks. If larger, decompose further.\n\n**Good**:\n- Calculate total of sale\n- Validate email of user\n\n**Too Large**:\n- Build complete checkout system\n- Implement entire authentication\n\n### 2. Respect Class Ownership\n\nEach class should have a single owner (developer). This:\n- Reduces merge conflicts\n- Improves code quality (single responsible person)\n- Enables expertise development\n\n### 3. Regular Builds\n\nIntegrate and build every day or even more frequently. This:\n- Catches integration issues early\n- Maintains working software\n- Enables continuous progress tracking\n\n### 4. Use Parking Lot for Communication\n\nThe parking lot diagram is your primary communication tool:\n- Share with stakeholders daily\n- Use in stand-ups\n- Display prominently\n- Update in real-time\n\n### 5. Chief Programmer Role\n\nChief Programmers should:\n- Be senior developers with domain expertise\n- Lead design by feature sessions\n- Conduct code inspections\n- Coordinate with class owners\n- Report progress\n\n### 6. Inspections Are Critical\n\nBoth design and code inspections:\n- Catch defects early\n- Share knowledge across team\n- Maintain code quality\n- Should be brief (30-60 minutes)\n\n## Parking Lot Diagram\n\nThe parking lot is FDD's signature artifact:\n\n```\n┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐\n│  User Mgmt      │  │  Shopping Cart  │  │  Payment        │\n│                 │  │                 │  │                 │\n│      85%        │  │      45%        │  │      100%       │\n│                 │  │                 │  │                 │\n│  17/20 features │  │  9/20 features  │  │  15/15 features │\n└─────────────────┘  └─────────────────┘  └─────────────────┘\n    🟡 Yellow           🔴 Red               🟢 Green\n\n┌─────────────────┐  ┌─────────────────┐\n│  Reporting      │  │  Admin Panel    │\n│                 │  │                 │\n│      0%         │  │      12%        │\n│                 │  │                 │\n│  0/25 features  │  │  3/25 features  │\n└─────────────────┘  └─────────────────┘\n    ⚪ Gray              🔴 Red\n```\n\n## Comparison with Other Methodologies\n\n| Aspect | FDD | Scrum | XP | Waterfall |\n|--------|-----|-------|-----|-----------|\n| **Team Size** | 15-500+ | 3-9 | 2-12 | Any |\n| **Iteration** | 2 weeks | 1-4 weeks | 1-2 weeks | Months |\n| **Progress Tracking** | Parking Lot | Burndown | Story Board | Gantt |\n| **Planning** | Feature-based | Sprint-based | Story-based | Phase-based |\n| **Code Ownership** | Individual | Collective | Collective | Individual |\n| **Documentation** | Moderate | Light | Minimal | Heavy |\n| **Best For** | Large teams | Small teams | Technical excellence | Fixed requirements |\n\n## References\n\n### Official Resources\n- [Feature Driven Development Official Site](http://www.featuredrivendevelopment.com/)\n- [FDD Parking Lot Diagrams](http://www.featuredrivendevelopment.com/node/1037)\n- [FDD Processes](http://www.featuredrivendevelopment.com/node/574)\n\n### Articles & Guides\n- [Monday.com FDD Guide 2026](https://monday.com/blog/rnd/feature-driven-development-fdd/)\n- [Wikipedia: Feature-Driven Development](https://en.wikipedia.org/wiki/Feature-driven_development)\n- [A Practical Guide to FDD](http://www.nebulon.com/fdd/)\n\n### Books\n- **\"Java Modeling in Color with UML\"** by Peter Coad et al. - FDD foundations\n- **\"A Practical Guide to Feature-Driven Development\"** by Stephen Palmer and John Felsing\n\n### Academic Papers\n- De Luca, J. & Coad, P. (1999). \"Java Modeling in Color with UML\"\n- Palmer, S. R., & Felsing, J. M. (2002). \"A Practical Guide to Feature-Driven Development\"\n\n## Troubleshooting\n\n### Features Too Large\n\n**Problem**: Features taking weeks to complete\n\n**Solution**:\n- Decompose into smaller features\n- Aim for 2-hour to 2-week range\n- Use sub-features if needed\n- Example: \"Process payment\" → \"Validate payment info\", \"Charge credit card\", \"Generate receipt\"\n\n### Parking Lot Not Updating\n\n**Problem**: Parking lot shows no progress\n\n**Solution**:\n- Ensure features are marked \"promoted\" after build\n- Check integration process\n- Verify parking lot task is running\n- Review feature completion criteria\n\n### Merge Conflicts\n\n**Problem**: Constant merge conflicts\n\n**Solution**:\n- Review class ownership assignments\n- Ensure one owner per class\n- Consider refactoring to reduce class coupling\n- Use feature branches with frequent integration\n\n### Design Inspections Slow\n\n**Problem**: Design reviews taking too long\n\n**Solution**:\n- Limit to 30-60 minutes\n- Focus on critical design decisions\n- Use checklists\n- Include only key team members\n\n## License\n\nThis methodology implementation is part of the Babysitter SDK and follows the same license terms.\n\n## Contributing\n\nTo improve this FDD implementation:\n1. Review the backlog in `methodologies/backlog.md`\n2. Propose enhancements via issues\n3. Submit pull requests with improvements\n4. Share real-world usage experiences\n\n---\n\n**Implementation Status**: ✅ Implemented\n**Last Updated**: 2026-01-23\n**Version**: 1.0.0\n",
    "documents": [
      "specialization:feature-driven-development"
    ]
  },
  "outgoingEdges": [
    {
      "from": "page:library-feature-driven-development",
      "to": "specialization:feature-driven-development",
      "kind": "documents"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:index",
      "to": "page:library-feature-driven-development",
      "kind": "contains_page"
    }
  ]
}