Learn how development teams can use the five phases of feature-driven development to put Agile principles into practice by structuring projects around app functionality.
Agile is one of the most popular development methodologies today, in part because it encourages teams to break development work into discrete phases.
On its own, Agile provides little concrete guidance about what those phases should include. Agile is a high-level development philosophy that doesn't offer much in the way of specific, step-by-step guidance.
Frameworks such as feature-driven development, however, help to close this gap. Feature-driven development is essentially a form of Agile that adopts a more specific and structured approach by organizing projects around featuresand dividing work into five distinct phases.
What is feature-driven development?
Feature-driven development (FDD) is a software development methodology that organizes work around application features or functionality. When developers adopt a feature-driven approach, they identify a handful of specific features to implement or improve and complete that work before moving onto working on a new set of features. As long as there are enough developers working on the same app or project, they can be divided into smaller groups -- usually called feature teams -- with each team focusing on a specific set of features or feature updates.
In this way, feature-driven development helps to translate high-level Agile philosophies, which encourage developers to break complex projects into smaller, easy-to-manage tasks, into actionable steps. By using features to define units of work, FDD provides a pragmatic way to put Agile into practice.
FDD focuses the broad steps of Agile on specific application features.
What features does feature-driven development focus on?
The term feature is used somewhat loosely in the context of feature-driven development. It can refer to application features in the traditional sense, such as a capability that enables users to place an item in a virtual shopping cart or check out. However, the meaning extends beyond application functionality.
Improving the page load speed of a virtual shopping cart could also count as a feature -- so could modifying text size and color within an application to improve usability. These updates don't add new functionality; they improve upon existing application features. For the purposes of feature-driven development, they also count as features that can help to organize work.
Benefits of the feature-driven development process
When implemented successfully, feature-driven development offers several significant benefits:
Clear scope of work. By aligning units of work with specific features or feature improvements, FDD makes it easy for developers to estimate exactly how much time and effort will go into each task.
Iterative progress. Breaking projects into small units of work helps teams work efficiently and iteratively. Rather than trying to make major changes to an application all in one go -- a difficult task to coordinate -- FDD enables developers to take small steps as they continuously improve an app.
User-centric approach. Because FDD focuses on features, it maps the work that developers do onto the functionality that users value.
Efficient communication and consensus among developers. When development work aligns with features, it becomes relatively easy to define tasks. In this way, FDD minimizes the need for meetings or back-and-forth discussions between developers to decide what they'll work on. With FDD, teams can quickly settle on a set of tasks and then start implementing them.
Challenges of feature-driven development
On the other hand, feature-driven development can present some challenges.
By using features to define units of work, FDD provides a pragmatic way to put Agile into practice.
One of the biggest challenges of FDD is making changes that affect multiple features or the application as a whole. For example, to refactor a monolithic application into a microservices app, the feature-driven approach doesn't work because developers have to make extensive changes beyond implementing or updating a specific feature. Likewise, if developers want to enhance an application's security, it may be difficult because doing so could impact a number of different features, such as the way users log in, how the app processes data and how it interacts with the network. This task can't be boiled down to a discrete feature.
FDD can also be challenging when developers lack a clear perspective on which features users value or when they need to support multiple groups of users with competing interests. In these cases, it may take longer to decide which features to work on because it's not obvious what creates the most value for the average user.
A third major drawback of FDD is that it doesn't work well for projects that only have just a few developers -- or, possibly, a lone developer. If there aren't enough developers to assign different tasks to multiple teams simultaneously, FDD delivers less value because it doesn't enable programmers to work in parallel.
The phases of feature-driven development
To put feature-driven development into practice, most teams work through five formal steps, or phases.
Phase 1. Create an overall model
First, they should establish a high-level vision for how their application will work and which categories of features it will include. This process involves formulating hypotheses about which types of functionality users value, as well as making technical decisions about how best to implement key requirements.
For example, if developers are designing an e-commerce app, they might decide during this phase what the basic customer journey within the app looks like and which key types of functionality, such as the ability to create accounts, search for products and make purchases, the app needs to support.
Phase 2. Build a feature list
Next, developers create a feature list that details which capabilities they need to implement to create the type of application they envisioned in the previous phase.
For instance, if the ability to create accounts is part of the application model, specific features associated with that capability might include registering a new account, authenticating users and providing ways for existing users to update their account details.
Phase 3. Plan by feature
Once teams have reached consensus on a list of features, they can begin planning how to implement them.
At this phase of the feature-driven development lifecycle, teams typically estimate how much time and effort each feature requires. They then decide how to delegate the work between feature teams.
Design by feature is about making specific plans for how to implement each feature. This task is usually overseen by a chief developer who works with each feature team to make decisions, such as which language or framework to use and, if applicable, how the user interfaces with the feature.
Phase 5. Build by feature
Finally, developers implement features based on the designs they established in phase 4. If a feature ends up taking substantially longer to complete than expected, the team might decide to redesign it or break it into a smaller set of tasks.
This process continues until teams have built and tested all planned features. At that point, developers are ready to plan and implement a new set of features by working through a new iteration of the feature-driven development phases.
Chris Tozzi is a freelance writer, research advisor, and professor of IT and society who has previously worked as a journalist and Linux systems administrator.
