Using Feature Trees to Depict Project Scope

Karl Wiegers
Oct 22, 2019 · 6 min read
Image for post
Image for post

A software feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. Many business analysts use features as a way to describe the scope of a project. However, a simple list doesn’t readily show the size and complexity of various features. Nor does quickly skimming a feature list easily reveal the full scope of a project.

A feature tree is a visual analysis model that organizes a set of features in a format that makes them easy to understand and assists with allocating features and subfeatures to development iterations or product releases. See my article “Defining Project Scope: What’s In, What’s Out” for descriptions of other techniques for representing scope.

Feature Tree Format

The structure of feature trees is based on fishbone, or Ishikawa, diagrams, which are commonly used to organize information into logical groupings based on relationships. Fishbone diagrams are typically used to model cause-and-effect relationships, but feature trees use the same format to organize the planned features of a software solution.

A feature tree can show up to three levels of features, commonly called level 1 (L1), level 2 (L2), and level 3 (L3). L2 features are subfeatures of L1 features, and L3 features are subfeatures of L2 features. Below L3 lie individual requirements, which aren’t shown on the feature tree. A feature tree does not necessarily need to have three levels of features; if the solution and features are simple, you might have just L1 features and their more detailed functional requirements.

As Figure 1 illustrates, the basic building block of the model is a feature with a single line. The feature names are simply shown as words on the tree, and the lines link related features together. Feature names should be concise, typically just two or three words.

Image for post
Image for post

Each feature is shown on its own line. Each subfeature also has its own line, which branches off the parent feature’s line. In Figure 1, the L1 feature has been decomposed into four subfeatures at the L2 level. The order in which the subfeatures are attached to the line is not important, as long as common subfeatures branch off the same parent feature line. The L1 features can be shown in boxes, to highlight those elements on the tree as being the main features under which subfeatures fall. This enables anyone who skims the model to understand the big picture of the scope of the solution.

A Sample Feature Tree

Figure 2 shows a partial feature tree for a chemical-tracking information system. The main branch or “trunk” of the tree is a straight line with an oval at the end that shows the name of the product being developed. The shaded boxes represent the L1 features, such as Order Chemicals and Inventory Management. Each such feature represents a block of logically related functions that a user might want to perform.

The lines coming off an L1 branch are the L2 features: Search and Chemical Request are subfeatures of Order Chemicals. The branches off an L2 branch are the L3 features: Local Lab Search and Catalog Search are subfeatures of Search.

Image for post
Image for post

Using the Feature Tree

A feature tree is typically created early in a project to define the breadth of work that will be completed, but it is useful throughout the project to communicate changing scope and to help the team members organize and coordinate their work. You can include a feature tree in the project’s vision and scope document or project charter, or it can be stored elsewhere and referenced as needed.

A key purpose of visual models like the feature tree is to foster clear and accurate communication among the project stakeholders. That clarity is more important than dogmatically adhering to the rules for a “correct” diagram.

Release Planning

Feature trees can be used during release planning to decide and show which features are allocated to each release or development iteration. A feature could be implemented in its entirety in a specific release, or only a portion could be implemented by choosing just certain L2 and L3 subfeatures. Future releases could enrich these rudimentary implementations by adding more L2 and L3 subfeatures until each feature is fully implemented in the final product.

The scope of a particular release or iteration thus consists of a defined set of L1, L2, and/or L3 features chosen from the feature tree. You can illustrate these feature allocations across releases by using colors or font variations. For example, in Figure 2, the blue features might represent the first release, the red features the second release, and the black features are yet to be allocated to a release.

Functional Decomposition

Feature trees show all of the planned product features at once, giving a quick view of the solution’s breadth of functionality. Organizing the features in this fashion makes it easy to identify missing and unnecessary features. The feature tree facilitates a functional decomposition of the solution for use throughout all phases of the project, including organization of the requirements, planning the work around the requirements, and bounding the scope of work. Feature trees provide a much richer view of features than a simple list can show.

Find Gaps

There’s no way to guarantee that a feature tree is complete. Therefore, have your stakeholders review it to make sure it reflects their expectations. The earlier that gaps are identified the better, because finding them late in a project can derail the project (and traumatize the participants). Update the feature tree any time scope is changed to reflect the final planned feature set. The visual nature of the feature tree helps customers, managers, and planners to understand the major components of each feature and to identify subfeatures that are missing, unnecessary, or of low priority.

Depict Project Scope

The feature tree should be used to set and communicate the scope of the project. It is a useful model to circulate among executives and lead stakeholders to quickly communicate the scope of the solution. Because you can fit so many features on one page, the feature tree is a good choice when you need a diagram that anyone can look at to understand the gist of the solution quickly. For packaged software, a feature tree provides the features that go in a short bullet list or description of the product’s functionality.

When a stakeholder joins a project midstream it can be a challenge for him to get a high-level picture of what an existing system does or what a new system is supposed to do. Feature trees allow all team members to understand and agree on the capabilities of the solution at a high level. They show the breadth of the solution scope at a consistent level of depth.

Organize the Requirements

The divisions in a feature tree provide a convenient way to organize requirements in deliverables so that the information is grouped by feature. In a requirement deliverable, all of the requirements for each L1 feature and its subfeatures can be grouped together. For the example discussed earlier, there could be a full set of models and requirements for Inventory Management and another for Health and Safety.

If your team is frustrated by the limitations of text-only requirements documentation, consider using feature trees to provide an at-a-glance visual representation of project scope.


This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.

Analyst’s corner

We are passionate about helping businesses do their job better!

Sign up for Top business analysis stories

By Analyst’s corner

A curated collection of recent stories from the Analyst's corner. Never miss an insightful article worth reading! Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Karl Wiegers

Written by

I’ve written on software development and management, consulting, self-help, chemistry, military history, and a mystery novel. More info at

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Karl Wiegers

Written by

I’ve written on software development and management, consulting, self-help, chemistry, military history, and a mystery novel. More info at

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store