We are looking to move to Jira from another ALM tool, but I'm confused about how to plan our Releases and Sprints. Maybe the community can help me understand this better. Both Releases and Sprints use Issues (Stories, Defects, and Tasks) as their fundamental building blocks. Sub-tasks seem to be essentially "hidden" within Issues and are mostly irrelevant the Release and Sprint planning process. We typically execute many Sprints as we march towards a given Release. Sprints are 1-2 week timeboxed periods, while Releases come a few times a year. So this adds tension since Sprints and Releases use the same fundamental building blocks, but want them to be different sizes: * Sprints need smaller Issues so they can fit into 1 or 2 week time boxes * Releases like larger Issues so the Release Notes avoid communicating every incremental step along the way. Perhaps a solution would be a hierarchy, with Releases being planned at the parent level and Sprints at the child level. But Jira doesn't support planning Sprints with Sub-Tasks and Stories, Defects, and Tasks cannot have parent/child relationships...they are all siblings. I suppose I could use Epics to plan Releases, but I tend to think of Epics as longer initiatives that span multiple Releases. If I used Epics to plan Releases, I would need to artificially carve up up Epics into smaller bite-size Epics simply to fit them into Releases.

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

How to plan Releases vs. Sprints?

Eric Hammes_ubjmrn

We are looking to move to Jira from another ALM tool, but I'm confused about how to plan our Releases and Sprints. Maybe the community can help me understand this better.

Both Releases and Sprints use Issues (Stories, Defects, and Tasks) as their fundamental building blocks. Sub-tasks seem to be essentially "hidden" within Issues and are mostly irrelevant the Release and Sprint planning process.

We typically execute many Sprints as we march towards a given Release. Sprints are 1-2 week timeboxed periods, while Releases come a few times a year. So this adds tension since Sprints and Releases use the same fundamental building blocks, but want them to be different sizes:

Sprints need smaller Issues so they can fit into 1 or 2 week time boxes
Releases like larger Issues so the Release Notes avoid communicating every incremental step along the way.

Perhaps a solution would be a hierarchy, with Releases being planned at the parent level and Sprints at the child level. But Jira doesn't support planning Sprints with Sub-Tasks and Stories, Defects, and Tasks cannot have parent/child relationships...they are all siblings.

I suppose I could use Epics to plan Releases, but I tend to think of Epics as longer initiatives that span multiple Releases. If I used Epics to plan Releases, I would need to artificially carve up up Epics into smaller bite-size Epics simply to fit them into Releases.

Accepted answers

All comments

Bill Sheboy

Hi @Eric Hammes

You seem to have listed most of the options people will probably suggest.

I have a question: are your Issues (story, task, bug) individually releasable to production? You note a want to "avoid communicating every incremental step along the way", so perhaps they are not releasable.

If they are releasable, you may want to list them associated to release versions, giving you a full accounting for the release candidates' contents. This could be independent of any epics used to manage larger bodies of work, possibly spanning both sprints and releases.

Kind regards,
Bill

Eric Hammes_ubjmrn

Bill, thanks for taking the time to reply. It is unfortunate that I've already considered most of the approaches. I was hoping Jira offered something else that I was missing!

And yes, we do our best to make every Issue releasable.

I guess I would be OK if all the Issues were listed in the Release Notes, as long as they were somehow grouped together or nested under a parent or something. I wouldn't want them to be spread out in some random order like date created or Issue ID or something.

Or is there some way to include an Issue in a Release, but exclude it from the Release Notes?

Trudy P Claspill

Hello @Eric Hammes

Have you considered using an advanced roadmap tool to enable you to extend the hierarchy of issues?

In that case you could set the Fix Version to a higher level than Story/Task/Bug and have only the higher level item info show up in the Release Notes.

Atlassian has their own Advanced Roadmaps extension for Jira Data Center, and there are also third party apps available in the Atlassian Marketplace.

Additionally you can generate release notes for publication. And it looks like you have the opportunity to modify the release notes text after generation, per the documentation.

https://confluence.atlassian.com/adminjiraserver/creating-release-notes-938847219.html

Bill Sheboy

Looking at the references Trudy provided, there is more flexibility for the release notes with Server/Data Center version. Please take a look a the tutorial for information on formatting the notes produced.

If you need something more, you may want to investigate addons from the Atlassian Marketplace.

David Wuth

We use epics to capture the features being delivered in a release. Then we create stories under the epics as a breakdown of the work. Stories can be no more than 8 story points, a typical max for being able to complete in a two-week sprint. We tag both the epic and the child stories to the same fixversion (release) in Jira. But, only stories are assigned to our sprints. Sub tasks are rarely used, but when they are, it is for a story that has multiple steps or multiple resources, and when all of the subtasks are expected to be completed in a single sprint, same as the parent story. We have Jira Cloud Premium so we have the issue type of Initiative that sits above the epic. Initiatives can span multiple releases, but we have a rule that an epic has to be completed in a single release. These are all out-of-the-box issue types for Jira. If you need additional levels of hierarchy, I suggest looking at Structure for Jira, an app from a third party that has very good reviews. We almost bought this app before Advanced Roadmaps was made available.

Eric Hammes_ubjmrn

I could see us following something similar to your approach. I might end up using Epics like you do, to group together a handful of related Issues within a Release. Good insights.

Unfortunately we are using a shared Data Center instance in our corporation, so I don't have enough sway to install a marketplace app like Structure...especially one with a fee. It also means that I don't have access to Jira Cloud's Initiative Issue type, so I'll lose the higher level tracking when we use Epics like this.

Eric Hammes_ubjmrn

Are you saying to search the app marketplace for an "advanced roadmap tool"? Do those types of apps typically supplement Jira with the ability to nest Issues into a hierarchy?

Unfortunately we are using a shared Data Center instance in our corporation, so I don't have enough sway to install a marketplace apps. But at least I'll have a background education if I end up talking to them!

Trudy P Claspill

Yes, such tools enhance Jira functionality by providing functionality that "extends" the issue hierarchy. Different tools may implement that in different ways.

If you have Jira Data Center v8.15 or newer then you already have access to Atlassian's built in Advanced Roadmaps feature at no additional cost.

https://www.atlassian.com/blog/jira-software/jira-data-center-includes-advanced-roadmaps

According to that same page you can get the same app from free from the Marketplace if you are running an older Jira Data Center version.

And here's a link to the Jira DC Advanced Roadmaps documentation. Select the version in the upper right that coincides with you Jira version.

https://confluence.atlassian.com/jirasoftwareserver/discover-advanced-roadmaps-for-jira-1044784153.html

Nic Brough -Adaptavist-

I came to this question with several snippets of various essays to talk about, but Trudy, Bill and David have covered almost everything in them.

The one bit I want to add to their stories is just the point that releases and sprints are not really related. A sprint is a time box for a team in which they (try to) deliver a product increment. A release is a curated package of stuff that is probably ready to go to production.

It is unusual that a release would include things that are not the result of a sprint, but your sprints don't have a lot to do with releases. A sprint provides some stuff that is ready to go into a release, but only from the point of view of the team doing the sprint.

The release should be considering everything from the user's point of view - one of your sprint teams might have provided a fantastic function that your users will love, but if it depends on other stuff other teams have not delivered yet, it's not going to work, so it's not going into the release.

All a sprint can tell you about releases is "this stuff is ready for you to look at including in your release"

Welcome!

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

Quick Links

Find more posts tagged with

server

jira

jira-server

hierarchy

sprint

release