Adding an issue to more than one Epic or Version

Big Jim July 23, 2017

Hi

I have set up Jira the following way:

Epic = Test 

Issue = Test Module

Multiple test modules make up a test. Sometimes test modules are included in more than one test. Can I add the same issue to two Epics or two Versions ?

The Version/s field seems to indicate multiple versions are possible but I can't find how to add and issue to multiple versions.

Thanks

Jim 

1 answer

1 accepted

2 votes
Answer accepted
Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 23, 2017

One Epic per issue but you can have multiple versions per issue. The idea of Version/s is to convey which versions an issue was fixed/added to. Example: lets say I have 1.1, 1.2.3 and 1.3.1 live in the field and I'm working on release 2.0. A customer reports an issue in 1.2 and I plan to address this issue in 1.2.4, 1.3.2 and 2.0. All three of these releases can be added to the Version/s field.

Big Jim July 23, 2017

Thanks Jack,

Very clear explanation. Could you let me know how in Jira I add an issue to more than one release ? I couldn't see how to set this up.

Cheers

Jim

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 23, 2017

If you are using the Fix Version/s field you simply select the field and start typing. A space will equate to completing the version at which point the next entry will be a separate version. If the release is predefined it will autofill and you can select. If you do not have the version predefined it will create it so be careful that you don't create nonsensical release names.

Big Jim July 23, 2017

Thanks again Jack. When you say a space will equate to completing the version. My aim is to include one issue in two versions (tests) which are both ongoing (not completed). I'm trying to establish that a developed module is included in multiple tests. This is possible ?

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 24, 2017

Sorry poor choice of words. The space is the separator between version. The only way to 'close' a version is on the release screen. Yes you can designate any number of versions in this field regardless of their release status (released, in progress, planned). This last fact is what gave me challenges in the past since, w/o knowing the status of a release some unsuspecting audience wouldn't know if the fix was in a release w/o knowing the status of the release and from the view screen that isn't clear. The release view is a good way to help with this as it shows what is in a release and the status of the release. Of course this relys on someone keeping that info up-to-date.

Big Jim July 24, 2017

Thanks. What was really confusing me was that I could see the associated version in the issue but when editing this was not visible. I had to add the version field to the screen and then it worked fine !

 

Like David Witherspoon likes this
David Witherspoon August 15, 2023

I realize this is an old question, but I have something to follow up on. But I'm trying to understand the best way to target a change, with it's work elements, and then indicate where it was completed.

Following from above, I have versions 1.1, 1.2.3 and 1.3.1 live in the field and I'm working on release 2.0. A customer reports an issue in 1.2 and I plan to address this issue in 1.2.4, 1.3.2 and 2.0.

What's the right way in JIRA to target the change to these versions? Fix Version?

For each of these versions, there work to do to make the change, test the change, update documentation, etc. Is there a best practice to make sure all these work elements are account for in JIRA so their progress can be tracked?

And then let's say we get it done in 1.2.4, but decided not to do it at all in 1.3.2. So it could have been targeted to 1.3.2, but never completed. So that's where recording completed versus targeted are important. 

Thanks in advance for advice.

Suggest an answer

Log in or Sign up to answer