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

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!

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.

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.

Hi @Kamil Stepien ,

Full disclosure: I work for Huminder, the company behind Board Studio for
Jira Cloud®.

Yes, your Release Package idea is a sensible model for this problem. I would use
it when a release is a real delivery commitment with its own owner, dates,
status and dependencies, especially when that commitment spans several Epics,
teams or Jira projects.

The important part is to keep three concepts separate:

1. Fix Version says which project release a work item belongs to and carries
the version dates.
2. Release Package represents the accountable delivery commitment that
coordinates several pieces of work.
3. Blocks / is blocked by records a real delivery constraint between two
work items.

On Jira Premium, I would add Release Package to the hierarchy above Epic and use
the native parent relationship for scope:

Release Package → Epic or Feature → Story, Bug or Task

I would normally keep the Release Packages in a dedicated releases project,
while the Epics and Stories remain in their product projects. Each package gets
an owner, start date, due date, status, exit criteria and a portfolio Fix
Version.

One detail that becomes important across projects is Product. Jira Versions and
Components are project scoped. If Product must mean the same thing everywhere,
a global single select Product field is usually cleaner than trying to
combine Components from several projects.

How this complements the answers already here

The previous answers cover the main options well.

@Olga Cheban _TitanApps_ is right to point to the Jira Plans Dependencies view. I would keep Plans as the canonical hierarchy and scheduling view rather than replacing it.

Several answers also recommend a dedicated releases project plus a Marketplace
tree, graph, roadmap or gadget. Those are reasonable presentation choices once
the Jira model is sound. Joshua's warning about governance is important too: if
scope is represented by ordinary issue links, teams must maintain and interpret
those links consistently.

The SAFe option is relevant when the organisation already works with ARTs and
Planning Intervals. I would not introduce that operating model solely to make
release dependencies visible.

What I would add to the discussion is:

1. On Jira Premium, use the native hierarchy for Release Package scope instead
of simulating containment with ordinary links.
2. Record each technical dependency once at the delivery level, then roll it up
visually instead of copying it onto every parent.
3. Load the complete hierarchy into the visualisation, not only the Release
Package items, so the release view retains its Story evidence.
4. Keep the distinction between a visible blocking chain and a calculated
critical path.

Before adding the new hierarchy level, I would still ask one question: does one
Epic already represent one independently releasable outcome? If yes, an Epic
plus Product and Fix Version may be enough. Release Package earns its place when
one release genuinely coordinates several Epics or products.

Avoid duplicating dependency links

Use hierarchy for containment and Blocks links for causality.

If a Story in Identity blocks a Story in Checkout, record that link once at the
Story level. Do not copy the same dependency manually onto both Epics and both
Release Packages. That creates several lines for one fact and those copies will
eventually disagree.

A direct Release Package link is still useful when it represents a genuine
release governance gate, such as Checkout approval being required before a
coordinated market launch. The rule is simply one Jira link for one fact, at the
lowest meaningful level. The remaining challenge is making that same model
readable at release, Epic and Story level without recreating it for each
audience.

A concrete example

I tested the model with a small Aurora Commerce portfolio:

• 6 Release Packages, 13 Epics, 26 Stories, 5 company managed projects, 5 Product values, 3 direct release governance gates, 6 cross release technical dependencies recorded only at Story level

The Jira filter deliberately loads all 45 work items, not only the six Release
Packages. That is what allows the hierarchy and lower level dependency evidence
to remain available when viewing the release level.

The JQL is:

project IN (REL, IDP, SHOP, APPS, RISK) ORDER BY project, key

In Board Studio, the release map is produced as follows by setting a board structure at Release semantic level. Fix Versions is the field used as timeline basis (with timeline mode on to visualize as a Gantt chart with concurrent parallel cadences, Date Ruler activated too). Then Show links rolled up from child items is switched on to have lower hierarchical levels links surface a Release level.

The result is a time scaled view of six accountable releases across Product
lanes. Three edges are direct release gates. Six use the aggregate edge style (fat links)
because they come from Story links below the packages. No dependency was copied
to manufacture the release map.

Move from the roadmap to delivery impact

The roadmap answers where the release dependency sits. A release owner also
needs to know which delivery items are involved and how far the exposure
extends.

For Web Checkout 5.0, I select its package, open the Selection Inspector and
expand Upstream and Downstream impact to depth 3. I then use Show impact on
board and Frame impacted cards in the viewport.

In this example the Inspector finds 8 upstream and 17 downstream work items
within three hops, across the hierarchy and explicit Blocks links. This is not
just a list of six release boxes. It exposes the Epics and Stories that the
release owner may need to follow up across four projects.

Use AI only after the dependency model is explicit

I would not use AI to invent the dependency model. The Jira hierarchy, dates,
status and Blocks links should remain the source of truth. AI becomes useful
after that, when it turns the selected evidence into a decision brief.

For the same Web Checkout package, I expand AI insights, keep Hierarchy
coverage set to the selected item and its descendants in the board data, then
select Assess risk.

• The Identity token claims Story is in progress without a due date, while the
  blocked eight point payment vault Story is due 11 September.
• The fraud scoring contract is also in progress without a due date, while the
  blocked eight point checkout Story is due 18 September.
• The Release Package is due 9 October.

It then proposes two specific actions: confirm the completion date, acceptance
criteria and owner for each blocker.

What makes this useful for the original question is that the assessment is tied
to the selected release hierarchy and its Jira evidence. It also states its
limits: descendants outside the board were not checked, duration estimates are
missing, parent estimates are incomplete, and the downstream Holiday Commerce
package sits outside the assessed hierarchy. The output is advisory and should
be verified before acting.

Keep the evidence behind every rolled up line

Finally, a release level edge should not become an unexplained diagram line.

Selecting the aggregate edge from Identity Platform 3.2 to Web Checkout 5.0
shows that it comes from exactly one Jira Story link:

Publish signed token-claims contract v3 → Map identity claims to payment vault
profiles

The Inspector retains the source and target Story, status, direction and a link
back to the Story level. That gives the portfolio view an audit trail and gives
the release owner somewhere concrete to act.

One final qualification about “critical path”: these links expose blocking
chains and downstream impact. A formal critical path calculation also requires
reliable durations, calendars and scheduling constraints. I would call this a
dependency and impact map unless those inputs are available.

So my recommendation would be:

1. Add Release Package only for a real multi Epic or multi product commitment.
2. Keep Fix Version as release membership and calendar metadata.
3. Use native hierarchy for scope and Blocks links for causality.
4. Record each dependency once, where it originates.
5. Use Jira Plans for planning, then add a dependency focused view when you need
to explain cause, impact and ownership across levels.

My 2 cents,

@Frédéric Tardieu_huminder_ | Founder & CEO at huminder.com
Board Studio on the Atlassian Marketplace

Full disclosure: I’m part of the team behind the tool mentioned below.

Hi Kamil,

You’re spot on. Because Jira fixVersion fields are flat metadata, you can't map true blocking dependencies directly to a release container without some serious structural acrobatics.

Your proposed "Release Package" workaround is actually a highly effective strategy. A proven way to run this is to create a dedicated "Releases & Bundles" project:

1. The Container: Create each Bundle as a parent issue in this dedicated project.
2. The Dependencies: Use a checklist inside that ticket to verify shipping criteria, and use standard Jira issue links (blocks / is blocked by) between your Release Packages to map out your critical path.
3. The Roll-up: Link the child Epics and Features from your actual product sub-projects directly to these master release tickets.

The Missing Link: Visualizing It At a Glance

The real headache is that native Jira boards won't cleanly roll this multi-project, cross-release hierarchy into a simple timeline view.

This is exactly why we built Millarum Roadmap.

Once your sub-projects are linked to your master release containers, our tool pulls all that data into a single, high-level timeline view to help you manage shipping risks:

• Cross-Project Visualization: It maps out your Release Packages horizontally, letting you see sequencing risks and cross-team delivery paths at a single glance.
• Bundled Release Notes: Because it tracks the relationships between your master container and sub-projects, you can dynamically aggregate and view bundled release notes right inside the roadmap UI when pulling data from various product teams.

It keeps your Jira architecture clean while giving you the portfolio oversight you need.

If you want to see how it handles this exact multi-project layout, you can check it out on the Marketplace here: Millarum Roadmap

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)