Feature Driven Development

An Agile methodology for developing software, Feature-Driven Development (FDD) is customer-centric, iterative, and incremental, with the goal of delivering tangible software results often and efficiently. FDD in Agile encourages status reporting at all levels, which helps to track progress and results.

FDD allows teams to update the project regularly and identify errors quickly. Plus, clients can be provided with information and substantial results at any time. FDD is a favorite method among development teams because it helps reduce two known morale-killers in the development world: Confusion and rework./p>

First applied in 1997 during a project for a Singapore bank, FDD was developed and refined by Jeff De Luca, Peter Coad and others. The original project took 15 months with 50 people, and it worked; it was followed by a second, 18-month long, 250-person project./p>

Since then, it’s become a pragmatic approach ideal for long-term, complex projects looking for a simple but comprehensive methodology. While Scrum and new variations of Agile are more widely recognized methods (especially outside of software development), FDD can be a good option for software development teams looking for a structured, focused Agile methodology that can be scaled across the product organization and will deliver clear outcomes.

How is FDD Different from Scrum?

FDD is related to Scrum, but as its name implies, it’s a feature-focused method (as opposed to a delivery-focused method). Features are a foundational piece of FDD; they’re to FDD what user stories are to Scrum: Small functions that are, most importantly, client-valued.

“During FDD, a feature should be delivered every 2-10 days – which differs from Scrum, in which sprints typically last two, but sometimes four, weeks.”

FDD values documentation more than other methods (Scrum and XP included), which also creates differences in the roles of meetings. In Scrum, teams typically meet on a daily basis; in FDD, teams rely on documentation to communicate important information, and thus don’t usually meet as frequently.

Another key difference is the end user; in FDD, the actual user is viewed as the end user, whereas in Scrum it’s typically the Product Owner who is seen as the end user.

How Does FDD Work?

Typically used in large-scale development projects, five basic activities exist during FDD:

·         Develop overall model

·         Build feature list

·         Plan by feature

·         Design by feature

·         Build by feature

An overall model shape is formed during the first two steps, while the final three are repeated for each feature. The majority (roughly 75%) of effort during FDD will be spent on the fourth and fifth steps – Design by Feature and Build by Feature.

Teams using all Agile methodologies operate with the primary goal of quickly and effectively satisfying the needs of their customers; FDD is no exception.

However, the difference is that once a goal has been identified, teams following FDD organize their activities by features, rather than by project milestones or other indicators of progress

How is a Feature Defined?

In FDD, each feature is useful and important to the client and results in something tangible to showcase. And because businesses appreciate quick results, the methodology depends on its two-week cycle.