Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

What is the best practice for managing epics per version?


I am interested to hear how other users are managing their Epics and versions.

I can see two approaches:

  1. An epic may span across multiple versions
  2. An epic may only last for the duration of a single version

There may be other suggestions.

If you take approach 1, the drawback is that the Epic Burndown report and Epic Report may be of limited use. For example, if you have an Epic 'User management module' which contains some issues which will be completed in version 1.0, some for version 1.1 and then others which are just sat in the backlog, the Epic will never be definitively completed. You cannot filter these reports by version. Useful code change: Allow Epic Report and Epic Burndown reports to be filtered by version.

If you take approach 2, you get more control. You can run reports from 'User management module (1.0)' and 'User management module (1.1)' separately, and keep loose items in the backlog classified by epic, e.g. 'User management module (backlog)'. Once you release a version, you can close one of the epics off and move unfinished items into another one. The downside is that on the epics panel on the Scrum backlog view, ALL epics are always visible, just greyed out per version, regardless of whether you select 'All versions' or not. This facilitates moving them between epics but you end up with a high amount of clutter. 

For example:
Annotation 2020-07-15 100446.png
Useful code change: use Fix Version(s) field for Epic issues to control which Epics are visible for which version, rather than just greying them out if none of their linked issues exist in that version. Previously I got around this by adding some custom CSS in the announcement banner to hide them, but this is no longer possible in Jira Cloud.

How do people manage their Epics across versions?

Do they have Epics which could continue on forever, in which case it is more of a challenge to measure performance against completing that epic?

Do they have lots of smaller Epics but then just deal with the clutter in the epics panel?

Do they leave backlog issues unsorted and only move them into epics when they are planned for a release?



Log in or Sign up to comment