This sounds like scrum?

Yes, it is related but in FDD, features are the foundational piece. Features are to FDD what stories are to scrum. In addition, during FDD, a feature may be delivered every 2-10 days. In scrum sprints typically last 2 weeks, but may be up to four.

An overall model is formed during the first two steps, the final three steps are repeated for each feature.
The majority of the effort during FDD will be spent on the fourth and fifth steps – Design by Feature and Build by Feature – allow about 75% of your time for this.

The Development Manager coordinates the teams, similar to a scrum master. 

The Lead Programmer will lead a small one pizza development team. 

The Class Owners are individual developers creating features in smaller teams, often known as stream leads, they will do the actual coding whilst leading the feature for a their small, often temporary, team.. 

The Domain Expert helps map the user requirements and problem domain.

Whats the process?

1. Gather Data

‘Sprint Zero’ – step zero, call it what you will but the first step is to gather data and gain an accurate understanding of content and context.

• Understand your target audience
• Understand the why and what and for whom
• Gather any other research and facts that will help you decipher the ‘how’ (the next stage)

2. Develop an overall model

This is the outline, the high level solution. In FDD one often uses domain driven design, or at the very least domain object modelling to represent the concepts and their relationships. Between the team you should develop a relatively detailed domain model that will act as a rough outline for the system.

Do this in a mutable way. As development progresses, amendments and additions, new domain objects and greater detail and refinement will be added.

3. Plan your features

Using the research from step 1 (or sprint zero) define the features that will be required. You can think of these as stories, but will be more closely tied to individual product features. For example a story may span several features, this often means stories are hard to fit into a sprint and to coherently roll out. A feature on the other hand may be a button, graph or other tangible output. This makes the deliverable clear and concise and of course, using featureflow, manageable.

4. Design your features

The lead programmer will determine the feature, including a technical design. They will also determine the feature teams involved if there are more than one team. At the end of the design stage, the whole team may typically be run through a design review for input and feedback.

5. Build by feature

Using the feature technical design, overall model and feature definitions from the previous steps, the feature can now be developed. As with stories and sprints, this feature should take no more than two weeks, it is common, and advisable, for the process above to identify multiple discrete features to be developed and released. A feature should be a small vertical slice such as a UI element, the rest api, service and database to support the feature. It may involve multiple teams, use featureflow to easily keep them in sync. 

Use featureflow to enable this process

Featureflow is designed specifically for this process. Lets look at how you would use featureflow throughout the process:

Plan your features using Jira and featureflow

As you plan your features, you will typically create feature ticket in your chosen task software, for example in Atlassian Jira. At this point you should discuss with your team if you wish to create the feature behind a flag. Creating a featureflow flag for each feature in your feature list means you can develop the features asynchronously and merge early and often.

Featureflow has first class links into jira, so you can see the real-time status of your feature directly in your feature jira ticket as it progresses through to production.

1. Install featureflow from the Atlassian Marketplace if you have not done so already

2. In your Jira feature story click ‘Add feature flag’ – you can then create a new feature or link and existing feature if you have already defined one in featureflow.

3. Your feature status will be available from within jira

Build by feature with featureflow

Using featureflow, you can release the front end, middle or back end code at any time with no bottle necks, they  when you are ready, enable the feature for your internal team to demo. If things look good, enable it for the greater public.

Iterate

The next phase of feature driven development it to iterate on that feature. Using featureflow experimentation you can easily decide if the feature has met KPIs then iterate.

Create an experiment

Featureflow experiments are both simple and powerful, they clearly present a winning variant.

Take this winning variant as input when deciding the next iteration feature improvements.

For more information, check out www.featureflow.com