Get The Insights!
The fastest way to learn about Product Growth, Management & Trends.
What is a feature-driven (FDD) development model?
Feature Driven Development (FDD) is an agile framework that is organized around developing features to satisfy the needs of the customers.
The definition of a feature in FDD is a bit wider and resembles user stories in other agile frameworks. An example would be “complete the login process.” They need to be broken into smaller tasks for the development teams to complete.
The happy path of a login process here illustrates what the process entails in reality. It could potentially help the team break the feature down and develop.
What is the main difference between feature-driven development and Scrum framework?
The main difference is the role of the end-user. In FDD, the actual user is often involved in the development of the product. Whatever the team develops, is designed with them in mind.
In Scrum, it is the Product Owner that serves as the voice of the customer. They represent them but there is no direct involvement of the user. As a result, FDD is a more customer-centered framework.
What’s more, FDD iterations are 2-10 days while Scrum sprints tend to be 2-4 weeks long.
In addition, the documentation in FDD plays a greater role. This is how team members communicate with each other. In Scrum and other agile development methodologies, documentation is not as important as direct face-to-face communication.
Why should you use feature-driven development?
Feature-Driven Development offers a number of benefits.
Easy to track progress with reduced risks
Thanks to small but frequent releases of software, it is easy for FDD teams to keep track of bugs and fix them. This reduces the risk involved in the delivery of new features.
More importantly, quick release cycles mean it takes very little time for the customer to get the features they need.
Move fast, at scale
One of the main advantages of FDD is that it allows teams to apply the main tenets of the Agile manifesto also to large projects.
On the one hand, feature-driven development is characterized by the consumer-centric approach and quick delivery cycles, like in other Agile frameworks.
On the other hand, thanks to the more extensive documentation, the FDD framework is scalable from small development teams to large multi-disciplinary teams working on complex long-term projects.
In Scrum and other agile methodologies, the role of face-to-face communication is so important, that it can only be used to manage small development teams.
In fact, the Scrum guide states that each team should not be larger than 9 people. If the software development project requires more team members, they should form separate teams led by separate Scrum masters. This creates new challenges.
FDD doesn’t restrict the team size at all.
And the added benefit of the FDD documentation is that it removes the need for so many meetings, which are an everyday reality for Scrum teams.
Feature-Driven Development facilitates incremental innovation
FDD is an interactive model in which frequent user feedback informs future feature development.
By releasing features every 2-10 days, the teams have a chance to analyze user data and feedback and iterate to better meet their needs and improve the overall product experience.
By having access to such frequent feedback, teams are able to work on very specific user pain points and hence drive incremental innovation.
Userpilot’s users are benefitting from such a feature-focused approach. This is how Andy Shamah, the Head of Product at Userpilot, summarizes it:
We started small focusing on the onboarding facet of the user journey and built slowly towards being the complete product growth platform – teams now use Userpilot for complex adoption plays, advanced engagement with their end-users, creating closed-loop surveys, experimentation, and much more.
We’re not done yet though. We’re on a continuous daily mission that we’re passionate about – figuring out the right puzzle pieces to put together the best product that better serves our customers’ needs and that’s one of the things that our customers love about Userpilot.
What are the steps in feature-driven development?
Feature-Driven Development follows a five-step cycle that revolves around feature development.
- Develop an overall model
- Build a features list
- Plan by feature
- Design by feature
- Build by feature
Develop an overall model
At this stage, the team defines the overall scope of the software development project.
They outline the target audience, the problems that the product is to solve, and the general context. They may also start brainstorming ideas around the user experience.
It’s important not to make the model too specific. If your feature team goes into too much detail and starts focusing on solutions too soon, they risk missing other opportunities.
Build a features list
At this stage, it is time to develop the list of features.
As we mentioned before, FDD features are very similar to user stories.
Good user stories describe not only the output of the activity but more importantly its outcome. In other words, they are not only about the actions the user performs but also their purpose.
Given that FDD teams may be large and have limited opportunities for direct communication, the development manager or the project manager may want to make the feature descriptions more detailed. The Gherkin template is a handy one to use:
- Scenario — the behavior you’re going to describe
- Given — the beginning state of the scenario
- When — a specific action that the user takes
- Then — a testable outcome, usually caused by the action in When
- And — this continues any of the other three operations if necessary
Here’s an example of how it works in practice, using the login scenario previously described:
- When logging into the app (Scenario),
- Given that I am the app user,
- When I enter my correct login credentials,
- Then I should log into the app successfully,
- And when I enter the wrong login details,
- Then I should be advised about it and prompted to try again.
When you make the list of features to develop, it’s a good idea to create a feature/story map. This helps you make sure the features are aligned with the product vision, the feature team is focused on delivering value to users, and the customers know where the product is heading.
Plan by feature
During the planning phase, the team breaks down the features into specific tasks and estimates the time and resources needed to build them. In traditional waterfall software development, this would be similar to creating the Work Breakdown Structure (WBS).
They also amend the story map with more details, such as deadlines for each of the features.
It’s important to engage all team members at this stage. Their expertise will make the estimates more accurate and their involvement means they are more likely to buy into the process.
Design by feature
At this stage, the development teams work collaboratively and iteratively to design the features that are to be developed next.
The chief programmer or project manager oversees the process. They help with feature prioritization, nominate class owners, and assign tasks to specific team members.
Build by feature
The iterative feature development continues. As the FDD teams are cross-functional, all aspects of development take place concurrently – the UI design, coding, and QA.
Feedback from frequent experiments and users allows to adjust the course and inform future iterations to ensure that the product satisfies the needs of customers.
What are the best practices of feature-driven development?
The best Feature-Driven Development includes:
- Domain Object Modeling.
- Developing by Feature.
- Individual Class (Code) Ownership.
- Feature Teams.
- Inspections.
- Regular Builds.
- Configuration Management.
- Reporting/Visibility of Results.
These are slightly beyond the scope of the article, but there are plenty of resources that will give you a more in-depth understanding of best FDD practices.
Identifying the next ”feature” to develop
The customer is at the center of Feature-Driven Development, so it is essential to seek their feedback. FDD, just like all Agile development frameworks, is an iterative process, so feedback collection should never stop.
Collect user feedback to identify needs
When it comes to user feedback, you can collect it either actively or passively.
We talk about active feedback when the company initiates the feedback collection. For example, this could be a survey that is triggered when the user completes an action, or an email asking for feedback.
Passive feedback is unsolicited. It comes from the users who voluntarily provide insights into how the product is working for them.
The company doesn’t do anything to initiate this but should provide the venue for their users to do so. This could be by designing feedback forms into the UI so that they are always only a click away.
Scouring the internet for comments on the product, e.g. on social media or review sites is another way to collect passive user feedback.
Track product usage analytics to identify friction points
Analytical tools allow you to track how users engage with the product features. For example, Userpilot enables you to tag specific features and track their usage.
Heatmaps and screen recording are other tools that can shed light on how users engage with features. They will clearly show you if specific features that you implemented are being used as designed, and if customers are staying on the happy path.
The data can help you identify the areas where your customers struggle. Friction increases the time to value and can even result in user churn, so these are features that you should prioritize.
Conclusion
Feature-Driven Development is an iterative software development framework that is suited for delivering also complex large-scale projects. FDD is very customer-centered and focuses on delivering functionality.
If you would like to learn how Userpilot can help you collect the data necessary for informed feature development, click on the link to get the demo!
About the author
