Adding an issue to more than one Epic or Version

[Big Jim]

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 

[Jack Brickey · Accepted solution]

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]

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]

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]

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]

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]

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 !

[David Witherspoon]

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.