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

Show fix version like an epic in plan mode

John Burns4

I just wanted to throw this question out there:

We use a Scrum board across many projects. We group our stories into sprints based on the fix version on the stories (so all issues for Project X v1.2 will be in the same sprint). We sometimes use epics to help with this. However, in this case, it would be simpler to just have the fix version display on the stories in the same way epics do. Would this make sense as a new Greenhoper option? or would this not be considered best practice?

Accepted answers

Renjith Pillai

You should use the old boards (Classic) in your case, if you need to filter issues based on versions.

Displaying the fixversions on the left may not be a good practice in the new boards as the boards can cater to mulitple projects.

You may use a quick filter in the boards using the JQL (earliestUnReleasedVersion) so that you can quickly filter the issues.

https://confluence.atlassian.com/display/JIRA/Advanced+Searching#AdvancedSearching-earliestUnreleasedVersion

All comments

boardtc

You mention plan mode, so I assume you are speaking about the new (Rapid) boards.

You probably are aware that the (rapid) board has resulted in a decoupling of Sprints from the Fix Version field, Fix Version is back to its intended use-case (showing which versions a bug or story can be found in).

So using fixVerision to group stories is not best practice with the new boards, if using the new boards sprints should be organised around the new Sprint field.

John Burns4

We do use sprints separately from fix Versions, but we generally still organize our sprints by versions. for example, "Sprint 10" may include stories from "project x v1.2" and "project y v2.3" because to ensure we have a releasable product at the end of the sprint, we want to make sure we include all work for a given release version. sometimes stories for a given version get spread across many sprints, if there is a big release and we want to do check points, or break the work up into smaller chunks, but the fix version information helps us with planning sprints. Am I off-base?

boardtc

You are not using fixVersion as now is recomended. It is hard to change mid project though. We are waiting until the end of our release and the start of a new project in January to stop using fixVersion to manage sprints as our complete feature release has used it - indeed that is the recommended path.

You are using a (Rapid) Board and best practice is that you do not manage sprints with fixVersion. Have you invested many sprints in using fixVersion like this?

Renjith Pillai

You should use the old boards (Classic) in your case, if you need to filter issues based on versions.

Displaying the fixversions on the left may not be a good practice in the new boards as the boards can cater to mulitple projects.

You may use a quick filter in the boards using the JQL (earliestUnReleasedVersion) so that you can quickly filter the issues.

https://confluence.atlassian.com/display/JIRA/Advanced+Searching#AdvancedSearching-earliestUnreleasedVersion

John Burns4

It looks like the Greenhopper team is working on an improvement to the quick filters to help with this: https://jira.atlassian.com/browse/GHS-4669