Is Feature Driven Development Right for Your Company?

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:

What is Feature Driven Development (FDD)?

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.

Members of a FDD team

A FDD team includes the following main roles: 

• Project manager: The project manager supervises and manages the entire project.
• Chief architect: The chief architect is responsible for the overall modeling of the system.
• Development manager: The development manager manages the development team and oversees its activities.
• Chief programmer: The chief programmer deals with analysis and designs. He is also tasked with managing smaller development teams.
• Class owner: Class owners are members of development teams that the lead programmer manages. They are responsible for design, coding, documentation and testing.
• Domain expert: The domain expert understands the customers’ problems they will focus on solving and guides the team.

As I mentioned, there are many more agile frameworks besides FDD. Why would you choose to use this one?

Why Do Companies Use FDD?

​​There are many reasons why companies use feature-driven development. Some of those include:

• Easy-to-use Insights: FDD companies provide a broad perspective and excellent understanding of the scope and context of the product. This allows for accurate insights.
• Fewer meetings: The biggest drawback of most agile methodologies for companies is the frequency of meetings. For example, the Scrum methodology is known for daily meetings for improved communication. On the other hand, FDD relies on documentation rather than meetings for communication.
• Customer-centric approach: For FDD, the end user is customers. Therefore, it offers a customer-centric approach to the company.
• Suitable for large-scale projects: FDD is ideal for projects that span across multiple months and are on a large scale. This is because this methodology is scalable and adaptable to the project’s growth.
• Reduces coding errors: FDD breaks feature sets into smaller, more manageable chunks. This allows you to notice coding errors more easily. So, you minimize the risks.

Is Feature Driven Development Necessary for Agile?

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.

Stages of Feature-Driven Development

Feature driven development consists of five clear steps:

1. Develop an overall model
2. Build a features list
3. Plan by feature
4. Design by feature
5. Build by feature

 Let’s start the explanation from the first step.

Develop an overall model

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.

Build a features list

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.

Plan by feature

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.

Design by feature

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.

Build by feature

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.

How Important is UI in Feature Driven Development?

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.

Best Practices for Feature Driven Development

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

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.

Individual class ownership

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.

Inspections

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.

And How Do You Track the Results of FDD?

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.

Collecting feedback

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.

FAQs