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

Creating new hierarchy levels in Jira Roadmap

Jerry Raterman_dc39tf

My currently contracted company uses a Jira hierarchy starting at Initiative followed by Epic, Stories, Tasks and Sub-tasks. For a specific multi-team project, I need to add a level, a Phase to go between Initiative and Epic. Can anyone define if/how I can do this? Can I do this without impacting the boards or views of the other participating project teams? Thanks for your help! Cheers.

Comments

Trudy P Claspill

Issue Type Hierarchy is defined at a global level. Any change affects all projects.

If you insert a level between Epic and Initiative the parent/child relationship will be broken between all existing Initiatives and Epics.

It is not possible to have different hierarchies per project.

Matthew Pavlovich_8jz2et

Agree inserting a level causes problems globally but you can have different combinations of issue type hierarchy per project as each hierarchy level allows for more than one issue type, hence your project issue type scheme can reflect that.
You still have to follow the hierarchy level constraint of parent/child but just highlighting the slight nuance depending on what is trying to be achieved

Robin Surland_qx626i

You have two questions here.

1. How do I add a new issue type above Epic when I already have on there names Initiative. Answer: Remove Initiative from the hierarchy, then add Phase. Afterwards, add Initiative back above Phase.

2. Can I make a hierarchy change for only one project? Answer: No.

Can you describe what this team is trying to accomplish with an issuetype of Phase? It feels more like a status qualifier that could be handled with a custom field.

Jerry Raterman_dc39tf

Thanks for the feedback received this far. To answer a question for more info, we are trying to group work by Phases: Planning, Preparation, Build, Handover in a new project with no existing tickets. Each Proejct Team will post Epics consolidating all of their stories and tasks under one of these phases. Each Team is working under either Scrum or Kanban, the Scrum teams are working to varying Sprint cycles. We want each Project Team to manage their Epics to their cadence. The Project Team would like to group these Epics together so that any slippages in the Planning Phase impacts all tickets until the Phase is complete. Given that it is not possible to change the issue hiearchy by just for this one project, are there any other ways to achieve this same functionality? Cheers once more!

Matthew Pavlovich_8jz2et

Hey @Jerry Raterman , thanks for providing more context.

As soon you explained 'Phase' better i can suggest a different approach ive used effectively many times.

Issue types are great for capturing context, providing encapsulation, measuring progress and understanding dependencies. But creating complexity for time boxing in your hierarchy, as you found, is a global impact... and theres an option out of the box below!

What you seem to be after is a time period that can group relative issues and demonstrate demand & progress within that time box. Id use 'Release' for this. The out of the box functionality (OoTB) of Release and Versions implies only a developer/build use case for it... but simply its just a start and end time box that you can call whatever you want, tag multiple per issue and it provides great OoTB reporting, contextualization on boards and best of all works built in with 'Plans' (which then also provides a cross release consolidation too).

So when i talk with clients about 'Releases', i say just think of them as a time box capability that you can name - Phase 1, Phase 2, Milestone, Build, Test, Discovery etc... whatever you want, and it allows great reporting and rollup of any issue/issuetype associated with it. Many PMOs have used this effectively while not impeding how different teams may want operate

Jerry Raterman_dc39tf

Brilliant Matthew. I can set the Release OOTB for my own project only? I will give it a try. Much appreciated!

Jim D

Hi Jerry,

It should probably be mentioned that the traditional hierarchy for Jira is as follows: Initiative, Capability, Feature, Epic, Story, Task, Subtask. Yes, you can disable certain issue types per project, however this can start to cause problems if you start having different teams working together with their own setup.

Karin van Driel

Nice description @Matthew Pavlovich, I was going to suggest this, but less eloquently

@Jerry Raterman
Another suggestion is to look at Jira Product Discovery for your specific project. It has more of a roadmap feel to it and you can link delivery tickets to it, that will sit in your hierarchy. The JPD tickets themselves do not fall into the hierarchy of the Plan, so it is separate in that way. You can use the JPD free plan, as long as you don't have more than 3 people that require edit capability of the 'idea' tickets you create in JPD. Creators/commenters/reviewers are unlimited. Might be worth exploring if you wanted to have a roadmap that precedes the creation of your Initiatives.

Karin van Driel

And to answer your question about releases, they are project specific, but in your plan you can create cross-project releases if you want to, which would roll multiple releases into one in your Plan.

One thing to call out, the naming in Jira for Releases is not very consistent; they are also called Versions. So the Releases you create in your project are tied to your issues through the Fix versions (fixVersion) field.

There is also a field called Affects versions (affectedVersion), which is more meant for bugs, to indicate which version of your software a bug was found in, so for your use case this is probably not useful.

Welcome!

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