nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Multiple releases assign to a specitif issue

BrosseauDamien _Consultant_

Hi, I'm using Advance Roadmap and cross projects releases.

Advance Roadmap doesn't allow the allocation of two releases on a single issue so I can't assign the cross-project releases to issues which already have a projet release.

anyone can confirm this behaviour and suggest any workaround ? Thank you !!

Accepted answers

Mykenna Cepek

NOTE: Half of what I wrote here is WRONG. See remainder of the thread below.

The short answer is: that's just how Jira works.

The "Fix Version" field (aka Release or Version) is not a multi-select field, it can only contain a single value. That field (and only that field) is what Jira uses for Advanced Roadmap releases, and for the Releases (Versions) portion of Jira projects.

The general concept is that an issue, once fixed (done), will be in a release and deployed. Deploying the same fix or feature multiple times (e.g. in several releases) doesn't achieve anything.

I'm guessing that your use-case is that different parts of the business (e.g. different teams or groups) have their own Releases, but yet might rely on the same work to be completed. To my understanding, Jira doesn't directly support that one-issue-to-many-releases model.

One of the strengths of Jira's approach is that, for any given Release, you can get a definitive list of everything that was included. This is great for things like release notes, figuring out if/when thing X actually was released, etc.

As for workarounds -- if your overlapping releases are hierarchical, then using Themes or Initiatives as layers above Epics might be useful for you. More here. But I suspect that's not what you really want.

All comments

Mykenna Cepek

NOTE: Half of what I wrote here is WRONG. See remainder of the thread below.

The short answer is: that's just how Jira works.

The general concept is that an issue, once fixed (done), will be in a release and deployed. Deploying the same fix or feature multiple times (e.g. in several releases) doesn't achieve anything.

BrosseauDamien _Consultant_

In Jira, the "Fix version" field is a multi-select field (see example with 5 fix versions)

Anyway, your answer is very helpful and helped me understand my approach was not good

Mykenna Cepek

Wow, you're right. Bad assumption on my part. I would have liked to add strikeout to the stuff I got wrong in my original answer. I added a NOTE instead.

Hint: the "Fix Versions" field is plural for a reason. :-/

Some further testing shows that Advanced Roadmaps only seems to show an issue under one of the Releases that is included in the Fix Versions field. Changing the order of Releases in the Fix Versions field didn't seem to matter. Not sure how Advanced Roadmaps decides which release to put an issue in.

Due to that non-determinism, it seems like Advanced Roadmaps simply does not support multiple Fix Versions well. It would be too weird, really, to have one issue appearing in multiple places in a Roadmap when grouping the display by Release, for example.

What I've seen in practice in Jira (without Advanced Roadmaps) is that an Epic is used group a larger effort that can span multiple releases, and the Story-level issues in that Epic are assigned the appropriate FixVersion for when they are released. This helps a team focus on burndown to a specific release, for example, while staying in the context of the larger Epic. And the Epic burndown helps track that wider effort.

Dave

Hi @BrosseauDamien _Consultant_,

The reason that Advanced Roadmaps doesn't allow you to assign multiple releases to an issue is to the impact this would have on the scheduling algorithm ("Auto-Schedule" in the new interface but previously known as "Calculate" in the older Live Plans interface).

If an issue is assigned to more than one release then it presents a challenge to know how to schedule that issue. Although a simple answer might be that you just take the earliest release, it's possible that you can have multiple releases with no fixed start or end dates.

Whilst this is not an insurmountable problem to solve it has never been a high enough priority (and demand not great enough) for it to be addressed. In the previous Live Plans interface it was only possible to generate a roadmap via the scheduling algorithm, but in the new interface it is possible to manually create one so there is considerably less reliance on it.

I appreciate that this isn't solving your problem but I thought it might be helpful to provide some context on why the limitation exists.

Regards,

Dave

Mykenna Cepek

It seems like the auto-scheduler algorithm could assume that an issue with multiple releases should be scheduled to be completed for any of the releases.

But the single-release behavior is baked in now, and as noted, it's unlikely to change.

For those wanting to vote up this feature:

https://jira.atlassian.com/browse/JSWCLOUD-20703

unknown

Isn't it more so related to this bug...?

https://jira.atlassian.com/browse/JSWCLOUD-20704

Lucy Dilts_rfe46i

I didn't come across this issue. Hmmm. The ticket just shows up under both Fix Versions in Advanced Roadmaps.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

advanced-roadmaps