What is FDD in Agile?

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.

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.

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.

Stage 0: Gather Data

As with all Agile methodologies, the first step in FDD is to gain an accurate understanding of content and context of the project, and to develop a clear, shared understanding of the target audience and their needs. During this time, teams should aim to learn everything they can about the why, the what, and the for whom about the project they’re about to begin (the next few steps will help clarify the how). This data-gathering can be thought of as stage 0, but one that cannot be skipped. To compare product development with writing a research paper, this is the research and thesis development step.

Once teams have a clear understanding of their goals, the targeted audience and their current (and potentially, future) needs, the first named stage in FDD can begin: Developing an Overall Model.

Develop an overall model

Continuing the research paper metaphor, this stage is when the outline is drafted. Using the “thesis” (aka primary goal) as a guide, the team will develop detailed domain models, which will then be merged into one overall model that acts as a rough outline of the system. As it develops and as the team learns, details will be added.

Build a features list

Use the information assembled in the first step to create a list of the required features. Remember, a feature is a client-valued output. Make a list of features (that can be completed in two weeks’ time), and keep in mind that these features should be purposes or smaller goals, rather than tasks.

Enter: Tasks. Analyze the complexity of each feature and plan tasks that are related for team members to accomplish. During the planning stage, all members of the team should take part in the evaluation of features with the perspective of each development stage in mind. Then, use the assessment of complexity to determine the order in which each feature will implemented, as well as the team members that will be assigned to each feature set.

This stage should also identify class owners, individual developers who are assigned to classes. Because every class of the developing feature belongs to a specific developer, someone is responsible for the conceptual principles of that class, and should changes be required to multiple classes, then collaboration is necessary between the owners of each to implement them.

And while class owners are important to FDD, so are feature teams. In feature teams, specific roles are defined, and a variety of viewpoints are encouraged. This ensures that design decisions consider multiple thoughts and perspectives.

“Kanban provides a shared, single source of truth that enables teams to not only manage support tickets more effectively, but also add infinitely more value to the product organization.”

A chief programmer will determine the feature that will be designed and build. He or she will also determine the class owners and feature teams involved, while defining the feature priorities. Part of the group might be working on technical design, while others work on framework. By the end of the design stage, a design review is completed by the whole team before moving forward.

This step implements all the necessary items that will support the design. Here, user interfaces are built, as are components detailed in the technical design, and a feature prototype is created. The unit is tested, inspected and approved, then the completed feature can be promoted to the main build. Any feature that requires longer time than two weeks to design and build is further broken into features until it meets the two-week rule.

Feature-Driven Development is a practical Agile approach suited for long-term, complex projects. It is a suitable choice for development teams seeking a simple but structured Agile method that is scalable and delivers predictable results.