F is for Feature Driven Development

Feature Driven Development (FDD) is my favorite Agile methodology. I have been using it for a number of years and it works really, really well. Here is a quick intro to FDD that I wrote a while back.

An introduction to Feature Driven Development

Feature Driven Development (FDD) is an Agile software development methodology. It provides a simple 5 step process that focuses on the delivery of quality software aligned with business needs.

FDD has a strong focus on efficient, up-front scoping, planning and costing, which makes it easy to slot into enterprise project governance structures.

The 5 Processes

The five FDD processes are grouped into two phases; the “start up” phase and the ”construction” phase. The focus of the start up phase is around scoping and planning,

whilst the construction phase is focused on the iterative and incremental build of the solution.

By the end of the start up phase, a highly accurate business case can be created (if required by an organisation’s governance structures).

FDD Proceses

Process 1 – Develop an overall model

During this process the scope and the architecture of the solution are developed. This process generally takes the form of a number of half-day workshops involving all parties (stakeholders, architects, project managers, testers, developers, domain experts etc.). Outputs are typically story boards, deployment diagrams, use-case models etc.

Process 2 – Build Features list

During this process the solution is broken down into a list of features. A Feature is a part of

the solution’s functionality expressed in client or stakeholder terms. For instance:

  • Calculate the total amount of a Sale
  • Calculate the total quantity sold by a Retail Outlet for an Item Description
  • Determine the most recent Cash Register Assignment for a Cashier

This list is prioritized based on business needs, technical dependencies and risk. This process is typically completed in a workshop with all the participants of from process 1 and usually only takes a couple of hours.

Process 3 – Planning

In this process the features are grouped together into “Work Packages” and a project plan is built around the delivery of these work packages.

A work package is designed to be 2 weeks long, with the team deciding on how many features can be fitted into each work package. The end result of this process is a firm project plan for the delivery of the prioritised feature list. Costings for the project can then be easily derived from this plan.

Process 4 – Design by Feature

During this process the team perform the detailed analysis, design and design QA for the features in the current work package. As with all Agile methods this work is done with heavy involvement of the stakeholders and domain experts. Once completed the development of the Feature can start.

Process 5 – Build by Feature

This process is focused on the delivery of unit tested code into a build of the solution, ready for testing by stakeholders, testers and other interested parties. This allows for early integration, testing and feedback which is crucial for a modern software development project’s success.

Rinse and Repeat

After a work package is completed, the project plan is reviewed and work begins on the next work package. This allows the solution delivery to adapt to changing business requirements and needs.

Tracking in FDD

Tracking is a key aspect of FDD. All tracking is performed against features. During the Design by Feature and Build by Feature processes, a number of milestone dates are tracked. This provides early warning of any potential issues. For example:

Feature Tracking

As each milestone is met a percentage complete is calculated for the feature, missed milestones are highlighted in red on progress charts.

Additionally, velocity charts are used to validate that the project is on track. Typically a feature completed by week (actual vs. planned) chart is used for this:

Velocity Tracking

Finally a “parking lot” diagram is used to summarise the overall state of the project:

Parking Lot

Scaling FDD

FDD is easily scalable to various team sizes, for example a small sized project team might look like this:

Small project

Whilst a large project team may look like this:

Large project

With 3 coding teams working on different features in parallel.


Agile methods are a great way to effectively build software and FDD is an easy to follow and implement example of an Agile method.