Let’s go back to 1997. This was the year when a man named Jeff de Luca was working on a software development project in the banking industry. He was a member of a team of 50 people working on this project. He felt that this team should be much more aligned with customer needs. With this aim in mind, he designed a development model with five steps focused on developing features in short iterations.
And that’s how feature driven development came about. So what exactly is this model based on? What are the steps, and how should they be implemented?
You will find the answers to these questions and a lot more in this article.
Let’s start with the most basic question:
When you say agile, Scrum immediately comes to mind for most people. That makes sense because Scrum is one of the most common and well-known agile methodologies. But agile is not limited to Scrum. Other agile methodologies are also slowly but surely gaining popularity.
One of those methodologies is feature driven development (FDD).
FDD organizes software development through features and thus aims to meet customer needs. However, FDD’s definition of “features” is a bit broader than what most people are used to. These features do not have to be just generally understood product features. In fact, it’s more like user stories in Scrum and other agile methodologies. For example, “complete the login process” is considered a feature for FDD.
A FDD team includes the following main roles:
As I mentioned, there are many more agile frameworks besides FDD. Why would you choose to use this one?
There are many reasons why companies use feature-driven development. Some of those include:
FDD is one of the methodologies you can use for agile development. Now, just because we’re mentioning that it’s an agile methodology doesn’t mean that it’s necessary for your SaaS, but it may be the proper framework for your company.
Among the Agile methodologies, Scrum is the most well-known. That said, Scrum and FDD differ from each other in some ways. For example, Scrum is a delivery-oriented method. FDD, on the other hand, focuses on features. Also, FDD tends to work better for larger projects than Scrum.
When you consider all these features, FDD may seem more appropriate to you in some ways than other methodologies. You can also support Scrum with FDD on large-scale projects. So you can have an agile framework that will fully meet your project requirements.
Feature driven development consists of five clear steps:
Let’s start the explanation from the first step.
This stage is where you and your development team define the outline of the project. At this stage, you determine your target audience, the problem you want to solve and the expectations of your customers. You also start planning the user experience.
At this stage, there is a crucial point that you need to pay attention to: You should make sure that your first model is not too comprehensive and specific. If you get hung up on too many details and try to get results quickly, you will likely miss out on many opportunities. So create a model for yourself in general and always leave plenty of room for change.
At this stage, you have now identified the user issues you want to focus on and have created an overall model. Now it’s time to build your feature list.
When you hear ‘feature list’, don’t think of a list with dozens of features to be developed. As I mentioned earlier, features in FDD are very similar to user stories. And good user stories don’t just describe outputs of activities. Instead, they also define the result of that activity.
You can use many different templates to create a detailed feature list. I want to give you the Gherkin format as an example. Using this format will be very useful.
The template outline is as follows:
Scenario: The feature or behavior you will define
Given: Initial state of the scenario
When: Action that the user takes
Then: Testable output of the action in the When section
And: User action other than section When
For example, let’s say you are developing banking software like Mr Luca. In such a case, users may need a password that does not contain repetitive characters to sign up for the system. In this case:
When creating a password (Scenario)
Given that I am new to the app
When I set a password without repeating characters
Then I should be successfully logged into the system
And when I enter repeating characters
Then I should be informed about it and asked to try again.
It would also be great to create a feature map when you equip your feature list with features like this. In this way, you can see how well the features serve the vision of your product.
You have determined the features. Now it’s time to plan!
At this stage, you categorize features according to specific tasks. This allows you to estimate the resources and time required for each category more accurately.
You also make the feature map you created in the previous stage more comprehensive with all the information you obtained in this stage. For example, you add your predicted deadlines for each feature.
The most important thing at this stage is to involve the whole team in the planning process. Each team member can make the predictions as accurate as possible based on their expertise.
At this stage, you begin to implement the features you have planned. Your development teams work collaboratively to design each feature.
The control of this stage is with the lead programmer or project manager. They supervise the process and decide which features to prioritize. They also determine which class owners will be on the team with these features.
This is the final stage of FDD. What you need to do is to implement all the elements necessary to support the feature design. FDD teams are cross-functional. So all these elements (e.g. UI design, coding, quality assurance etc.) happen simultaneously.
You also often collect feedback from users at this stage. This way, you can be sure that your product meets customers’ needs. Moreover, you can check whether the features thoroughly perform their functions.
The user interface is the primary point of contact between your users and your product. In a way, your users’ first impressions of your product are shaped by your UI.
Let’s say you come up with a solution that will solve your users’ pain points. You have backed this solution with great features as well. These are almost irrelevant if you don’t have a neat UI. This is because users will not know what the product is for without a suitable user interface. In such a case, they cannot benefit from the product effectively. That’s why your UI must be a critical factor in every single step of FDD.
Now you know the steps to follow when implementing feature driven development. So how do you make all these stages better?
Let’s take a look at the best FDD practices.
Domain object modeling is an object diagram that illustrates the relationships between a problem and different object types. This model provides a comprehensive framework that details how to develop each feature.
Domain object modeling reveals how the features you specify will add value to the software. For this reason, it is indeed a worthwhile practice for FDD.
In FDD, a class owner can be part of more than one feature team. Also, for example, the lead programmer of one feature may be the class owner of another feature. In such a case, it is crucial that each developer is assigned as the lead developer for only one feature. This speeds up the process and prevents confusion.
After developing any feature, it is vital to be sure of the quality of the feature. You should review the design and code of the feature. You should perform quality checks to make sure everything is fine and correct. And if you come across any inconsistencies or issues with the code, you should fix them as soon as possible.
It would help if you also ensure that the features match customer expectations. After all, if your feature doesn’t serve the purpose it was built for, it doesn’t matter how great the design is.
In FDD, it’s all about features that can benefit users. Therefore, it makes sense to use various product and feature metrics to measure the success of the process.
So which metrics will help you in this process?
The first thing to consider is your feature engagement. Tracking your feature engagement allows you to observe which features your users are engaging with. In this way, you can measure the rewards of your efforts and take the necessary actions to improve the user experience.
If you’ve embraced the feature-driven development approach, another thing you must track is the feature adoption rate. The feature adoption rate gives you a detailed view of your users’ interactions with features. The best way to monitor this is to take advantage of a feature adoption funnel.
The adoption funnel has four stages: Exposed, Activated, Used, and Used Again. If users go through all these stages for a particular feature, it indicates that your efforts for that feature have been successful.
Tracking all of these metrics and more throughout the process can give you real-time insights when needed. That said, this isn’t easy to achieve without having a powerful analytics tool.
Lucky for you, HockeyStack allows you to manage this whole process in the easiest way possible. With HockeyStack, you can visualize all the metrics you need and track them in real-time. You can also create many detailed funnels, such as adoption funnels. This way, you can be much more in control of the process.
You can also create customized dashboards with all the metrics and funnels you want with HockeyStack. This way, you collect everything you need on one page and reduce the chance of missing something.
The customer is at the heart of FDD. In such a case, customer feedback makes an incredible contribution to the process.
The most effective and fastest way to collect feedback is through surveys. For example, you can create a survey triggered when a user completes using a feature. This way, you can find out how your users feel about that feature, what they like and what they think is missing.
HockeyStack makes the survey creation process relatively easy. All you have to do is choose one of the dozens of survey types, add your questions and voila! Your survey is ready to publish.
The best part about using HockeyStack for your surveys is that you can also analyze these surveys in detail as if they were a funnel. Thus, you can better understand the innovations and changes required and work on more successful features.
Would you like to see what else you can do with HockeyStack? Start your free trial today to find out what else is in store.
Why should you use Feature Driven Development?
FDD is a pretty comprehensive process. Since documentation is a major part of feature-driven development, bugs are easy to track down and fix. This reduces the risk associated with introducing new features.
Is Feature Driven Development agile?
Feature driven development is an agile framework.
What exactly is HockeyStack? How do we help marketers drive revenue more efficiently?
Jump in to uncover the ins and outs of Marketing Mix Modeling – from its mechanics to its ideal applications – with Drew.
.svg){kind=icon}
.svg)
