The FDD consists of five main parts.
This stage follows a high-level approach to analysis, on the basis of which the teams combine sufficiently detailed so-called "domain models" into a system-level outline. They then refine the overall model.
This is where the feature list, evaluated by the client, is added. Here it is particularly important that a feature can fit in 2 weeks, if not, it is broken down into smaller parts in [plot] + [result] + [target object] approach. Here, it is more important to think in terms of smaller objectives when writing, rather than tasks.
This is where tasks are allocated, complexity is examined, the development plan is defined, development roles are assigned, and teams and developers are assigned to features and departments.
The target model and the development plan are refined, if necessary, for the features included in the sprint, and then the design review is carried out.
After successful design review and planning, developers start coding in their teams. Development is followed by testing, code review and sharpening of the finished features.
The FDD approach is more straightforward when you want to write an API (application programming interface) or backend feature where there is no user, so it can be contrived in the “I, like (user role), I want to (act) so I, like (business value)”, approach.
This way, features appear in the Product Backlog much easier to review and the Product Owner doesn't spend time addressing the API in a personalized way, so he can spend his time on better elaborating the Backlog items.
The form of the feature in the Product Backlog according to the FDD system:
[plot] + [result] + [target object]
Example:
Estimate a closing price for a stock;
Generate a unique identifier for the transactions;
Change the text in the display.
Our article was not intended to go into the details of the highly structured and complex model of Feature Driven Development, but to give a simple description to help general understanding, showing that in the Product Backlog user stories, technical tasks, bugs, tasks, features appear and do not necessarily follow the form requirements of the user story.
