Feature Driven Development for Web Developers
Ten years ago, most web projects were static and development was relatively straightforward. That’s changed. The gap between web apps and desktop software has largely closed, functional complexity keeps growing, and the demands on teams have shifted accordingly. Projects run longer, involve more contributors, and carry backlogs that evolve well into development. Goals and stories shift, tasks change shape, and time-based estimates become unreliable. You could try fitting a heavyweight process like Rational Unified Process (RUP) or Process Mentor to this kind of work. Or you could use something from the Agile family that fits more naturally: Feature Driven Development (FDD).
The approach breaks down into four stages:
- Develop Overall Model
- Build Feature List
- Plan By Feature
- Design and Build By Feature
Develop Overall Model
As Jeff DeLuca, the methodology’s author, put it: the overall model is more shape than content. It’s not just a list of requirements — it’s a vision of the project built from preliminary research. Drawing on Louis Rosenfeld’s work, we know how central information architecture is to web development. At this stage you want an analysis of the target audience, the content and how it will be used, and the content structure (including metadata and thesaurus). A document covering UI principles, proposed UI components, their properties and behavior is also worth having.
The idea is to start development with just the shape of the system, filling in details as features are built. Detailed wireframes come during feature development, not before.
All of the above results in documentation, but the key deliverable is the domain model: a static UML diagram covering the project’s logical objects and their relationships (composition, inheritance, and so on) as understood at this stage.
Build a Feature List
Most teams working in Scrum will find FDD’s feature list familiar — it maps closely to the product backlog. One thing worth noting: when building the feature list, work in goals and sub-goals, not tasks.
Plan By Feature
How do you estimate development time when full details aren’t visible yet? In FDD, you don’t estimate in man-days — you use Story Point Estimation instead. Features are assigned abstract points representing complexity. Start by identifying the simplest feature and assigning it 2 points (not 1 — the backlog is large and even trivial estimates can be off). From there, use a Fibonacci-like scale: 1, 2, 3, 5, 8.
Estimation meetings involve the whole team. Every feature is discussed from every angle until the team reaches a shared estimate. Exhausting, but effective.
Design By Feature
With priorities set, it’s time to specify the requirements for each feature. A Use Case model is created, and an Activity Diagram can be attached to visualize the logic of the involved use cases. Use cases themselves can also be represented as a Use Case diagram. The whole team reviews the document.
From here, work runs in parallel: part of the team produces the technical design while others work on wireframes (or refine them if they were started during the Overall Model stage). Technical design should include a UML diagram with domain model entities, class lists and diagrams, related models, DAOs, controllers, and services. It should also cover database architecture via an ER Diagram. If the feature touches external systems, include a Sequence Diagram for those interactions.
Test cases should be written at this stage to give QA a clear basis for validating the feature.
As the domain model takes shape, new details about the overall model will surface. That’s expected — just update the overall model as you go.
By the end of this stage, the whole team reviews the technical design. Beyond refining the document, it gives everyone a deeper understanding of the feature and how it fits the broader project.
Build By Feature
While the visual designer works on UI, developers can build prototype components from the technical design. Once the visual design and prototype are reviewed, frontend work begins: HTML templating, updating prototype views, and client-side JavaScript. QA tests the result.
Once a feature passes QA and ships, the cycle repeats with the next feature.