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

Question

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?

Frédéric Tardieu_huminder_ · Answer

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

Laura Marin - Millarum · Answer

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:

* The Container: Create each Bundle as a parent issue in this dedicated project.
* 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.
* 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

Joshua Brock _ Seibert Group_ GmbH · Answer

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)