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; } } }

Best practice using Releases and FixVersion

Meytal BM_tgpmuh

Hi all,

Our team gather requirements on a quarterly basis, and we have a quarterly planning where we decide what planned items goes into the next quarter.

In each sprint, we add these planned items (stories/tasks of Epics), but also some unplanned ones as well (70/30 ratio planned vs unplanned).

Instead of adding a custom field stating which Epic quarter that specific Epic is planned for, I prefer using Releases / Fixversion, etc as part of Jira Software. Also, I want to indicate that although unplanned items were added to a specific quarter during that quarter, it was not planned.

Therefore, I was wondering what is the best practice for using this in our situation?

thanks!

Accepted answers

Trudy P Claspill

As a variation on the first suggestion you could add another Version field such as TargetedVersion. When you are planning what will go into your release, fill in this field with the Version for that release. For any unplanned issues that get added, leave the field blank.

Then you could use filters such as

fixVersion=<value> and TargetedVersion is empty

...to identify the unplanned issues that were added to the release.

All comments

Warren_mz9b4z

Hi @Meytal BM

I'd like to throw 2 extra fields into the mix, although both of these would involve manually adding to each story that it applies to - these are components and labels. Their use is that you can set up queries and filters for stories that have one of these fields matching a specific value.

So you could say use a label of Unplanned for all stories that weren't planned and then you could run a query like

Sprint = 2 and labels = Unplanned

to get all unplanned tickets in a specific sprint, or just

labels = Unplanned

for all unplanned tickets. Once you've used a specific label, it will then show up like intellisense. Components are slightly different in that they are created prior to use but then can be used in the same way as labels.

I agree with your use of fixVersion to track releases, we do that and it is really useful, especially when we want to check which release a specific story went out in.

Trudy P Claspill

Then you could use filters such as

fixVersion=<value> and TargetedVersion is empty

...to identify the unplanned issues that were added to the release.

Meytal BM_tgpmuh

Thanks @Warren . I usually am not keen on using labels as they can get messy. But yes, I used a custom field "unplanned" = Yes/No instead. It would work the same, but I wanted something combined with the releases so that the team wont have to update so many fields/labels, etc.

thank u!

Meytal BM_tgpmuh

Thanks @Trudy P Claspill , so just to see if I understood:

1. Use FixVersion to reflect which version that item (epic/story, etc) was actually fixed/done

2. Use custom field TargetedVersion to reflect which version that Planned item (epic/story etc) was planned for. If it is = EMPTY then it was never planned.

3. What I don't get is how "Release" comes into play here. Appreciate your clarity.

Thanks

Trudy P Claspill

You have understood my recommendation correctly.

Release and Version are the same thing. You go to the Releases page to create and manage Versions

Meytal BM_tgpmuh

Thanks @Trudy P Claspill I am going to try this and let u know how it works out for us. thanks again everyone

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud