how to use Jira to visualise cross-release delivery dependencies?

[Kamil Stepien]

I'm trying to model dependencies across different product releases in Jira so we can create a master roadmap and clearly visualise delivery critical paths.

The challenge is that a release (fixVersion) cannot directly have issue links such as blocks / is blocked by. Because of this, I'm considering introducing another issue type that acts as a container for all releasable features planned for a given release.

For example, something like a "Release Package" issue type with:

• Assignee
• Start date
• Due date
• Description
• Ability to use issue links (blocks / is blocked by)
• Ability to associate a release/version
• Ability to associate one or more products/components

The proposed hierarchy would look like this:

• Release Package
  • Epic / Releaseable Feature
    • Story / Bug / Task

The main goal is to:

• Track dependencies between releases
• Visualise cross-team delivery risks and sequencing
• Build a higher-level roadmap view beyond standard fixVersions

Has anyone implemented something similar in Jira?
Would you recommend:

• creating a custom issue type like this,
• using Advanced Roadmaps differently,
• or modelling releases/dependencies another way?

[Olga Cheban _TitanApps_]

hi @Kamil Stepien !

Introducing a "Release Package" issue type is a sound pattern. It gives you a real issue with an assignee, dates, links, and components, and it lets you model dependencies between releases clearly. 

With Advanced Roadmaps (Jira Plans), dependencies can be visualized as lines or badges. In addition to the timeline view, Jira Plans include a dedicated Dependencies view. There, you can see all dependencies between work items across projects presented as cards connected with lines. For tracking and managing dependencies, this is just the thing. Here's what it looks like in Jira Plans:

 

Once the hierarchy is in place, the next pain point is usually visibility. Native Jira views can struggle to show a clean parent-child tree across projects, especially when Change Request, Release Package, Epic, and Story live in different places.

 Our solution Smart Hierarchy for Jira can help here. It gives you a tree view of work items across projects, so you can see Change Request > Release Package > Epic > Story in one place. 

Here's an example of what that view can look like:

It also contains roll-up values of progress and shows you the number of work items in different statuses.

I hope this helps!

[Danut M _StonikByte_]

Hi @Kamil Stepien,

Your solution, based on introducing a separate "Release Package" issue type above Epics, looks like a solid approach for tracking dependencies. However, for effective visualization and tracking, Jira’s out-of-the-box capabilities may not be sufficient. You might need to explore an app (plugin) from the Atlassian Marketplace to address that part more effectively.

If you're open to using a plugin, our Great Gadgets app offers a variety of gadgets that can help you track releases and their dependencies.

For your use case, the following gadgets could be especially useful:

Work Breakdown Structure (WBS) gadget in Linked Issues View mode with display your releases and their linked issues (dependencies) long with their status

Pivot Table & Pivot Chart gadget can display various stats about your releases based on child items in form of tables, heatmaps tables of charts of various types

For how to configure them see these arcticles:

• https://community.atlassian.com/forums/App-Central-articles/How-to-Visualize-Linked-Issues-and-Their-Status-in-Jira/ba-p/3150240
• https://community.atlassian.com/forums/App-Central-articles/How-to-display-the-progress-of-Epics-or-Initiatives-in-Jira-or/ba-p/2858840 

Danut.

[Shivam Sharma - Optimizory]

Hi @Kamil Stepien ,

The Release Package container approach makes sense, most teams land here once native fixVersions start feeling limiting. Custom work item type with dates, links, and version association works well in practice.

One tip: decide early whether these live in a dedicated "Releases" project or inside each product project, because that's painful to change later.

For the visualization piece, this is where your real challenge sits. Advanced Roadmaps can show dependencies but gets messy beyond a couple of hops, and spotting a true critical path is rough.

Atlassian Marketplace plugin "Links Explorer" gives you a proper tree/graph view of linked work items across projects, which is much closer to what you're describing. Orphaned items and blocked paths surface clearly, which sounds like exactly what you need.

One small push back: before adding a new issue type, check if an Epic with a custom "Release" field could carry the role. But if your container needs to span multiple Epics across projects, then yeah, new work item type is the right call.

Happy to go deeper on the setup if useful.