Releases are at the core of every project. They help teams organize the delivery of their work and act as a historic reference for future needs.

Jira releases are good for managing your releases at a project level. However, difficulties come when you try to use Jira for release management in multiple projects.

Release hierarchy in Jira

In Jira, you can create many projects, in each of these projects you can create issues. To track your issues better Jira offers several options to tag the issues. Like, Fix versions (aka Releases), Components, Labels, Epics, Sprints, Custom fields and many more.

  • Releases and Components are project-specific and can't be linked to the issues from different projects.
  • Labels and Epics in Jira are global and can be used to tag issues from any project.
  • Sprints are dependent on the board. If you run a board with issues from multiple projects then you can include any of them in the sprint.
Jira releases hierarchy - relationship between Fix versions and Projects
Jira releases hierarchy - relationship between Fix versions and Projects

So where is the problem? This hierarchy is just way too restrictive for cross-functional teams.

When the operation gets bigger teams often decide to split into many smaller projects in Jira. These projects can represent different teams, clients or parts of the operation.

This approach is especially helpful because each team can manage their own tasks, can have different workflows, reports, etc. But when it comes to releases they still need to release only one version that delivers tasks from several of these projects.

How to create cross-project releases in Jira
Share versions between projects in Jira

The solution for having the same Jira release in multiple projects is to create Fix Version (aka Release) with the same name in all needed projects. This will enable the ability to link issues to the needed version. Now we can also JQL by a version name to get the list of all issues delivered in the cross-project release.

But here is a thing, these versions aren't connected to each other. If we change the name, description, release dates or status we need to do it in all these projects manually. And this might become hardly manageable after a while.

Cross-project or portfolio releases aren't the core functionality of Jira. But, they can be added by using an external app like Swanly - Release Management Timeline.

How to create cross-project releases in Jira using Swanly

In Swanly you can create a release with multiple projects assigned.

There are 2 ways to create a cross-project release:

  • by creating a new release from scratch,
  • by adding additional projects to existing release.

Than Jira versions are automatically created in each selected project and any change done to any of these versions are automatically synchronised. Magic 🎩🐇

You can now assign the issues to these versions as usual and instead of updating Jira versions, you can focus on delivering your project.

Share Jira Versions Across Projects in Swanly
Assign multiple projects to the release

Swanly provides much more than only Jira cross-project releases sync functionality. It shows your releases on a portfolio release timeline or in a list view and also provides advanced release reports with:

  • Aggregated Story points and Time tracking,
  • List of the issues linked to the version and List of issues that affect the version,
  • Release History,
  • Release burndown chart,
  • Release phases/stages.

So you find everything you need in one place.

Tracking Progress of Jira Version across Multiple Projects
Track progress of cross-project releases in one place

TRY SWANLY FOR FREE