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.

[Joshua Brock _ Seibert Group_ GmbH]

Hi @Kamil Stepien 

The "Release Package" issue type approach you're describing is a legitimate workaround for the fixVersion linking limitation, and several teams land on exactly this pattern. Typically, you'd put Release Package issues in a dedicated project, then use issue links (blocks/is blocked by) to connect them to Epics and delivery work across your product projects.

As others have noted, you'll want a Marketplace app to make the resulting tree navigable — native Jira views struggle with clean parent-child display across projects once you add more than one hierarchy level above Epic.

One thing worth considering before you commit to this pattern: the custom issue-type approach requires manual governance. The hierarchy lives in issue links rather than a first-class data model, which means aggregating rollup values — capacity, progress, risk status across a release — requires Jira Plans or a third-party gadget to interpret those links each time. It works, but it tends to need ongoing maintenance as teams and projects grow.

If your team is operating in, or moving toward, a Scaled Agile Framework (SAFe) environment, there's a more structured way to approach this. The hierarchy you're describing, something above Epic that owns releasable features across multiple teams, with dependency tracking and timeline visibility, maps directly to the SAFe structure of Portfolio Epic → Feature → Story, orchestrated through an Agile Release Train (ART) and time-boxed Planning Intervals (PIs).

Agile Hive is a Jira-native app that enforces this as a first-class data model, not issue links. In practice:

• Full SAFe hierarchy in Jira: Portfolio → Solution → ART → Team levels, all backed by native Jira issue types — no data sync, no external system of record
• Cross-ART dependency tracking: dependencies between features across teams surface on a PI board with ROAM status, so blockers are visible before they become delivery risks
• PI scoping: your "Release Package" equivalent becomes a Planning Interval — a time-boxed scope container with committed objectives, assigned teams, and real-time progress, all inside Jira
• Portfolio roadmap: timeline views across ARTs and the portfolio, replacing the manual fixVersion + Advanced Roadmaps workaround
• Zero-sync architecture: everything lives natively in Jira — no reconciliation between systems

 
The honest caveat: Agile Hive is purpose-built for SAFe governance, not generic release dependency tracking. If you're coordinating one product team with simple releases, it's more structure than you need. But if you're managing multiple teams, tracking cross-product dependencies at the feature/epic level, and trying to build a credible master delivery roadmap — that's the exact problem it was designed for.

If you'd like, you can find more at agile-hive.com, and there's a free trial available on the Atlassian Marketplace.

And in full disclosure, I work at Seibert Group, the team behind Agile Hive.

Hope this helps!

Joshua
Content Writer and US Representative
Agile Hive & Aura Apps (products of Seibert Group GmbH)