I recently wrote about how to use process flows in agile projects. Process flows are one of the most commonly used visual model and most people intuitively create them to help them figure out the steps of just about anything. Today I’d like to talk about using another helpful visual model in agile, one that may not be as familiar – feature trees.
What is a feature tree?
A feature tree is an RML Objectives model that shows the full scope of features for a project or product on a single page in a tree format. A feature is just a short form description of functionality provided by the project or product that brings value to the end user. The feature tree is great for bringing new people on a project up to speed and showing executives, business stakeholders, or customers all the features that are in scope for a project or release.
The feature tree is similar in shape to a fishbone diagram, also known as an Ishikawa diagram, but it shows levels of features instead of root-cause analysis. It is easier to read than a flat list of features for a product because the feature tree groups them into logical buckets. The format of a feature tree is illustrated below:
How do I use a feature tree in agile?
On a waterfall project, a feature tree would be expected to show the complete project scope up front. But they are flexible enough to use really effectively in agile.
Feature trees are useful for almost any agile project because they are just a good way to organize information. The Product Owner (PO) or Business Analyst (BA) will usually elicit the start of a feature tree during a sprint 0 or planning phase, possibly with information from a project charter or light-weight business case. From there, the PO or BA will organize the features into groupings, understand the connections between feature levels, and identify if there are any gaps. Your backlog hierarchy will determine how you use the levels of your tree. Depending on the story hierarchy you are using on your project, you might use Epic > Feature > Story or Feature > Epic > Story for your L1, L2 and L3 with the story level being optional (see illustration below).
Since you won’t always know the full scope of the product during sprint 0 or planning, the feature tree is always evolving as the PO or BA finds new features to add to the backlog. The feature tree also helps organize the hierarchy of your backlog as you now have an easy visual of how things are related.
How to create a feature tree
Like process flows, feature trees are pretty simple to elicit and create. First, find out if there are any existing lists of features for the project or product from a vision and scope document or a project charter.
From there, host a brainstorming session to identify potential features and maybe even group them in a mind map. After that, decide the format for your features, depending on your organizational standards or backlog structure.
The model itself is pretty straight forward with only two elements:
- Trunk/Product Concept – On the trunk of the feature tree is the product concept. This is a short form phrase that says what the product or project is. If you’ve created a business objectives model for your project, the product concept is already written!
- Branches/ Feature – Coming out from the trunk are branches which have levels just like real tree branches. The primary branches are the L1 features. These L1 features will be further elaborated into L2 and L3 features (smaller branches) depending on your story hierarchy.
Use formatting strategically
You can add formatting to a feature tree to make it even more useful on an agile project:
- Color coding: You can color code the features by release or sprint/iteration, which makes it easy to see at a glance if certain features are in or out of scope for a release.
- Prioritization by location: You can order the feature tree such that more important items are closer to the “trunk” of the tree, allowing for visualization of the backlog prioritization.
- Gap Analysis or Current/Future State: Instead of color coding by release, you can color code for gaps or current vs. future state of the system (with red, blue, green, or little colored circles we like to call skittles)
Derive user stories from your feature tree
Once you have a good starting draft of the feature tree, you can basically pluck the backlog from its branches. Each L1 branch becomes a Program Epic or Feature (based on SAFe or generic agile hierarchies). The epics or features (again depending on your hierarchy) are pulled from the L2 branches, and L3 branches, if you use them may be features or user stories. See the example Feature Tree below:
A feature for “Create Station” might become the following work items in your backlog:
In conclusion
Feature trees, like process flows, are super easy RML models to use on agile projects and derive features, epics and user stories from because they organize the scope of a project or product onto a single page.
Executives, business stakeholders, and customer love this visual model because it shows them what is in and out of scope easily and potentially even shows them when they will get certain features. Developers and testers like the feature tree because it gives them the big picture of the entire project while they are working on specific user stories. Finally, the POs and BAs find this model useful for backlog population early in the project and maintenance throughout, so it is one of the most commonly used RML models on agile projects (second only to process flows!)
One note of caution is that because it is so easy to add additional features and scope to the feature tree and thus to the backlog, the PO or BA has to be vigilant in the management of the backlog to ensure that only the most valuable features get built for their project.
