Feature-Driven Development: A Brief Overview

Feature-driven development (FDD) is a five-step Agile framework that organizes software development around making progress on features in one to two-week sprints. The five steps are: 

• Develop an overall model 
• Build a features list
• Plan by feature 
• Design by feature 
• Build by feature

A feature in FDD does not always refer to a product feature; it could refer to a small task or process a client or user wishes to complete.  For example, “View all open tasks”, “Pay on-line bill”, or “Chat with my friends in the game.” Features in FDD are similar to user stories in Scrum.

As with other Agile software development frameworks, the goal of feature-driven development is to iterate quickly to satisfy the needs of the customer. The five-step process of FDD assigns roles and utilizes a set of project management best practices to ensure consistency, making it easier for new team members to onboard. 

Roles 

Before we can dive into the methodology, it is important to understand the six primary roles involved in a feature-driven development team. Each role serves a specific function throughout the development process, there may be more than one person in a given role on a team. 

The Project Manager is the leader of the whole project and coordinates all the moving parts, ensures deadlines get hit, identifies gaps in the workflow, and so on.   

 The Chief Architect creates the blueprint for the overall system. Part of their job is to educate the people on the team about the system's design so each person can effectively fit their individual tasks within the context of the whole project. The Chief Architect approaches the project from a holistic point of view.

The Development Manager coordinates all the teams ensuring they complete their tasks on time providing mentoring and leadership of programming activities. 

The Chief Programmer is an experienced programmer that leads a small development team, helping with analysis and design to keep the project moving in the right direction. 

The Class Owners are individual developers creating features on smaller development teams. Their responsibilities can include designing, coding, testing, and documenting the features or classes. 

The Domain Expert has detailed knowledge of the user requirements and understands the problem customers want solved. 

In addition to the six primary roles, there are eight supporting roles that may be needed:

• Release Manager
• Language guru 
• Build engineer 
• Tool-smith
• System administrator 
• Tester
• Deployer
• Technical writer

Feature-driven development methodology 

The first two phases of an FDD project focus on the overall project, the final three steps are repeated for each feature defined in the model. 

Step 1: Develop an overall model 

One of the core principles of feature-driven development is to use domain object modeling. Domain object modeling is a way to represent connected concepts and the relationships between them. During the first step, an outline of the domain model is created. This object model will be the blueprint for the project. 

The domain expert shares what business or user problem needs to be solved with the feature. The chief architect provides guidance to the team. The proposed models are reviewed and either one model or a merge of models is approved. At the end of the phase, the team has a clear understanding and picture of the project. 

Step 2: Build a feature list 

The list of features identifies the elements necessary expressed as actions, results, or objects. Each feature should be built in less than two weeks. Features taking longer than two weeks to develop should be broken down into smaller features. For example, if the feature you are building is “pay on-line bill”, some of the features on the list may include “validate account number” and “retrieve account balance”. 

Step 3: Plan by feature 

Once the feature list is created, you need to determine the order in which they need to be developed and implemented and which team member is responsible for each feature. All team members should take place in this process to identify potential risks, dependencies, workload constraints, and other obstacles. 

At the end of this phase, each feature should be assigned to a developer and feature team. 

Step 4: Design by feature

A design package is created for each feature. The chief programmer identifies which features will be included in each two-week iteration, as well as identify the class owners and feature priorities. The design phase ends with a design review by the entire team. And the domain expert ensures what was built addresses the customer problem being solved. 

Step 5: Build by feature 

After the design is approved, now it’s time to start writing code. All the items necessary to support the feature design are implemented. These elements can include front-end and back-end elements like user interfaces or database queries. Once everything is completed by individual team members the feature moves onto testing and the process begins again for the next feature on the list. 

Advantages to feature-driven development 

There are many Agile methodologies to choose from: Scrum, kanban, extreme programming (XP), or feature-driven development. What are some of the advantages the FDD process has over these other Agile methods for a software development project? 

Feature-driven development requires fewer meetings. Fewer meetings doesn’t mean a decline in communication; instead of relying on a daily standup to communicate updates and issues, FDD uses documentation. This is a plus for large teams or distributed teams that cover multiple time zones. Documenting asynchronous updates ensures that every team member is aware of what is happening. The documentation and 5-step process gives new team members a way to quickly get up to speed understanding the scope and context of the project. 

The short-iteration process of FDD is a great way to break large-scale projects into smaller chunks.

How feature flags complement feature-driven development

Feature-driven development pairs well with feature flags. Feature flags allow you to separate deploys from release, making features available to internal teams or a small group of users while development continues. 

One way LaunchDarkly aids with feature-driven development is by configuring dependencies across flags. We suggest keeping the reach of a flag small. You can create a flag for each feature in the feature list with a dependency on the overarching feature being developed. 

Just as the feature list breaks the functionality of a feature down into the smallest unit of logic, you can do the same with flags. Items from the feature list can be built behind individual flags that are hidden from users until the feature is ready for release.  

During the planning phase, identify the flag structure for the feature and tasks, which features need flags, and what dependencies exist. 

To learn more about ways feature flags can support feature-driven development, check out our definitive guide to feature management.