Feature relationship and dependency types

No matter what type of roadmap you have, you've run into dependencies from time to time. A dependency is typically defined as something that must be completed before other work can be done. In other words, 'feature B' is dependent on 'feature A' being completed. These types of dependencies can easily be created on the Releases Roadmap view by hovering over 'feature A' until a dot appears, grabbing it with your mouse and dragging it to 'feature B'. Done. 

However, sometimes you want to show a different type of relationship between features. This is all possible under the Actions menu in each feature.  Creating a link between two features shows a relationship about which you can track, manage and report.

To some degree how you define your feature relationships will be subjective depending on your environment. Depending on which feature you look it, the relationship is going to be active or passive in most cases. In our example above, 'feature A' has to be done before 'feature B' can be started. 'Feature A' is a dependency of 'feature B'. 'Feature B' depends on 'feature A'.

Therefore, there are six categories of links, five of which have two labels because it depends on your perspective which feature gets which label.

Depends on
is a dependency of

This is the most commonly used relationship and it's the only link you can create on the Release Roadmap view by dragging and dropping between two features. This is stating that one feature should be done before another one is started. If the due date of 'feature A' gets pushed out, it will automatically move out the start and due date for 'feature B' to accommodate the new schedule.

Relates to

This is the most generic relationship. When a feature is related to another feature in some way that's not easily defined by the other categories, but you want to show that relationship, you can use "Relates to".

is Duplicated by

If you have two products and both will use the same feature, you may still need to track the feature in both product roadmaps. The work only happens once so you should create a primary feature where the work will be done, and then create a second feature and link it to the primary. This helps you report but also keep track of the work.

is contained by

If you are working on a feature that will be part of another feature, you use this link to show the relationship. For example, you might be creating an alerting capability that's triggered by a report. You create the reporting capability in one feature but link it to the other feature for alerting capabilities.

is impacted by

This could represent a feature whose work will ultimately impact the design of another feature. In this example, you may wish to hold off on your design until the first feature's design is completed. 

is blocked by

This could represent a feature that completely blocks another feature because until it's done absolutely no work can take place on the other feature. Another example is that this feature uses a resource that you need and until it's completed, you are blocked. This relationship could be helpful in reporting tradeoffs you've made during the roadmapping process. 


Was this article helpful?
7 out of 8 found this helpful