Feature-Driven Development vs Scrum: Choosing How Your Team Delivers

“Are you Scrum or something else?” is one of the first questions clients ask a development partner. The honest answer is that the method matters less than whether it fits the product, the team and the stakeholders. Still, the choice shapes planning, reporting and quality, so it is worth understanding the options properly.

This guide compares Scrum with Feature-Driven Development (FDD) — a less widely discussed agile method that suits some situations particularly well — and explains how many teams combine elements of both.

Scrum in brief

Scrum is a lightweight framework in which a small team delivers a usable increment of product in each sprint. According to the Scrum Guide, sprints are fixed-length events of one month or less; most teams use one or two weeks.

• Roles (accountabilities): product owner, Scrum Master and developers.
• Events: sprint, sprint planning, daily scrum, sprint review and sprint retrospective.
• Artefacts: product backlog, sprint backlog and increment, with a product goal, sprint goal and definition of done.

Scrum’s strength is empiricism: plan a short horizon, build, inspect the result with stakeholders and adapt. It works well when requirements are uncertain and feedback changes priorities.

Feature-Driven Development in brief

FDD was devised by Jeff De Luca for a 15-month, 50-person project at a large Singapore bank in 1997, drawing on Peter Coad’s object modelling and feature-list ideas. It was later described in *Java Modeling in Color with UML* (1999) and in Palmer and Felsing’s *A Practical Guide to Feature-Driven Development* (2002).

FDD has five activities:

1. Develop an overall model of the domain with domain experts.
2. Build a feature list of small, client-valued functions, grouped by business area.
3. Plan by feature, assigning feature sets to chief programmers and classes to class owners.
4. Design by feature for small groups of features.
5. Build by feature, including code inspection and promotion to the main build.

Features are expressed in a simple action–result–object form, such as “calculate the total of a sale”, and each should take no more than two weeks; larger items are split. Progress is tracked through six milestones per feature with fixed weights — domain walkthrough 1%, design 40%, design inspection 3%, code 45%, code inspection 10% and promote to build 1% — so a feature is 44% complete when coding starts.

Side-by-side comparison

When Scrum fits better

• The product is new and the team must learn from users each iteration.
• The team is small (roughly ten or fewer) and cross-functional.
• Stakeholders can attend reviews and make prioritisation decisions regularly.
• The domain is not yet well understood, so heavy upfront modelling would be wasted.

When FDD fits better

• The domain is complex but well understood — for example, banking, insurance, logistics or a large replacement system with known rules.
• Several teams or many developers work on one product, and clear ownership reduces conflicts.
• Sponsors need predictable progress reporting against a defined scope.
• Design quality and consistency matter, and inspections are valued.

Hybrid models that work in practice

Many teams combine the two:

• Scrum cadence with FDD features: keep sprints, reviews and retrospectives, but write backlog items as small client-valued features in FDD’s action–result–object form.
• An overall model before the first sprint: a short modelling phase with domain experts reduces rework in complex domains without abandoning iterative delivery.
• Milestone tracking inside sprints: track design, inspection, coding and review for larger features to give stakeholders a truer picture than “in progress”.
• Inspections as part of the definition of done: design review for significant changes and code review for every change.

Choosing a model for an outsourced or dedicated team

When a client works with an external team, method labels matter less than shared agreements:

Fixed-price projects often lean towards FDD-style feature lists and milestone reporting, because scope is defined upfront. Dedicated teams working on evolving products usually lean towards Scrum or Kanban. Our guide to dedicated teams versus fixed price explains how the commercial model interacts with the delivery model.

Example: one project, two approaches

Consider a hypothetical insurer replacing its claims-handling system. Business rules are well understood and documented; 30 developers across four teams will work on it for a year.

Under Scrum, each team would work from a shared product backlog with a single product owner (or a scaled framework), deliver increments every two weeks and review them with claims managers. The domain model would evolve as stories are delivered — with a risk that teams model the same concepts differently.

Under FDD, the project would start with two to three weeks of domain modelling with claims experts, producing a shared model of claims, policies, parties and payments. A feature list of several hundred items — “calculate the excess for a claim”, “record a third-party payment” — would be planned by feature set and assigned to chief programmers. Sponsors would see progress as percentage completion per feature set each week.

A sensible hybrid would run the modelling phase, then deliver in two-week sprints with features written in FDD style, design reviews for complex features, and milestone reporting for sponsors alongside sprint reviews for users.

Common pitfalls

• Scrum in name only: sprints without working increments, reviews without stakeholders, retrospectives without change.
• FDD without the model: feature lists created without domain modelling lose the method’s main benefit.
• Over-precise reporting: milestone percentages are a guide, not an exact measure of value delivered.
• Ignoring quality: neither method works without automated testing and continuous integration.

Frequently asked questions

Is FDD still used?

Less often by name than Scrum or Kanban, but its ideas — small client-valued features, domain modelling, inspections and milestone tracking — are common in teams that build complex business systems.

Can FDD work with continuous delivery?

Yes. Features are small enough to build and release independently, and the promote-to-build milestone fits naturally with continuous integration.

Which is better for a startup MVP?

Usually Scrum or Kanban, because learning and changing priorities dominate. A lightweight domain model can still help in complex domains.

What about Kanban?

Kanban focuses on visualising work, limiting work in progress and improving flow, without fixed iterations. It suits support, maintenance and teams with unpredictable incoming work, and combines well with either method.