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

Should I use Epics or Versions for release planning?

Emile Silvis

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.

Accepted answers

Rahul Aich [Nagra]

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.

Rahul

All comments

Rahul Aich [Nagra]

hi Emile

Rahul

Emile Silvis

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.

Rei Kasai

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"?

Gary W Alvord

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.

Danny_yzl0xi

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.

bryan.bai@wdc.com

this is an interesting question. EPIC vs Version despite there have many difference. but stukl are similar metric in some situation, for example jira report have: EPIC burndown report and Release burndown report. they are like 2 different dimension to help development team to monitor a health progress.

some difference:

issue can have multiple Fix Version/s: which link to version (release)

issue can only belong to one EPIC

Welcome!

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

Quick Links

Find more posts tagged with

jira

project

epic

release

project-management