Should I use Epics or Versions for release planning?

I'm really new to Jira, so bear with me.

My question is whether I should use the "Epic" or "Version" construct to do release planning. Here's what I mean by release planning: let's say that we've got 40 stories, and we reckon it can be released in 4 chunks. Do we divide those 40 stories into 4 epics, or do we divide those 40 stories into 4 versions (or is there some other construct altogether I can use)?

Whatever I use, I'd like to view a board (Scrum and Kanban if possible) at a release level, as well as view reports at a release level.

Any guidance here is greatly appreciated.

2 answers

1 accepted

2 votes
Answer accepted

hi Emile

Releases are supposed to be managed by versions on jira. So, if you think that 40 stories are going to be released to your customer in four version, i would set up for versions and assign those 40 to each of the four fix versions.

Now, this has got nothing to do with scrum or kanban boards. You do not need to have a 1:1 relationship with each sprint mapping to each version release. Each sprint can contain multiple customer releases and multiple sprints can constitute a big version release.


Thanks Rahul, that makes complete sense. So to extend the example, I could divide the 40 stories up into 4 releases, but the 40 stories could also be divided into 10 epics being delivered over 5 sprints. So seems like the "Version" construct is the solution.

How do you handle multiple "projects" in one "version"? We are organized by multiple scrum teams. Each scrum team owns a project. Each PO for the scrum team wants to filter for their "project" and for a particular "version" (which is a release to us) as they only care about their team's deliverables.

Program management and product leadership want a cross team/program wide view. How do you roll up multiple teams "projects" into one release "version"?

This can be done via Jira Portfolio using cross-project releases. The user creating the cross-project release would require the necessary permissions within each project to commit Jira Portfolio changes to each project in the Portfolio plan. Each project would then contain a fix/Version release with the same name particular to the project's releases. 

0 votes

If your various project teams are careful to use the same spelling for each project's list of releases, then you may search across projects using that common release/version name.  This is also neat trick for Components.  The pitfal is each Version and Component must be created for each project - not so bad if you're watching over a handful of projects, but an arduous task if you have many projects.  Maybe someday Jira will allow the use of common list of Versions and Components.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted yesterday in United States

Atlassian acquires AgileCraft

         Good Day, Bad bad traffic, not sure why!!!! 1/2 hour commute took me 2 hours today 🤯 What helped me is that I kept browsing LinkedIn until...

59 views 4 0
View post

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you