Feature driven development (FDD) is an iterative agile software development model. More specifically, FDD organizes workflow based on which features need to be developed next.
There’s one important thing to note, though: in FDD, ‘features’ take a different meaning to what you may assume. In FDD, ‘features’ refer to tasks or user stories, e.g. “build check-out cart”, rather than specific product features, e.g. payment platform.
When embraced successfully, FDD can speed up development time and make space for continuous improvement to software releases, by leading teams through five key stages of development.
Learn how to prioritize by making it a simple process, to build products that stand out. Learn more about how to source insight, choose the right prioritization framework and much more.
In FDD, ‘best practice’ means following five stages of activity:
Here, teams should focus more on the shape and overall scope of the product than the detailed content. According to Jeff De Luca — FDD’s founding father — the overall model acts as a draft, capturing the vision of the product but not a lot else.
Go into too much feature-heavy detail at an early phase, and you may miss other opportunities that arise. At this stage, simply focus on capturing on paper who your target audience is, what context your software will be used in, the necessary content structure and first thoughts surrounding UX and UI.
Next, teams should use the overall model to identify which features will be required. Remember that in FDD, ‘features’ are similar to user stories — so think about the development activities which will need to happen to bring your product or software to life.
The planning phase is essential in FDD. Here, teams should allocate reasonable estimates to each feature, assign them to a team member and work out what needs to happen for these deadlines to be met. For ultimate success, all team members should take part in this process — so everyone is aligned with the plan of action.
Now it’s time to get started! As FDD is an agile practice, teams should design concurrently and collaboratively.
Again, team members should work on their individual build responsibilities at the same time — visual designers on the UI, programmers on coded components, etc. When everything is ready to be pulled together, it’s sent to QA for testing. Then, the next feature can be tackled.
These are many reasons your team may choose to use feature driven development, here are three of the most important:
Clearer project management: In FDD, the overall system is built progressively through feature development — planned, designed and built individually and then merged into the overall model. This makes managing the process easier, as there’s only one feature to focus on at a time (rather than managing the overall system at once).
Minimizing complexity: FDD breaks down the overall project into small components so that they can be delivered in short time periods. This helps the development teams to minimize the complexities associated with the system development process. If your team tends to run behind on development timelines, FDD could get you more organized.
Building better products: FDD model is an iterative model that allows the software development team to intermittently showcase the product, either internally or to the client. Because of this transparency, frequent feedback can be received and the software can be collaboratively improved as a result.