Creating new hierarchy levels in Jira Roadmap

[Jerry Raterman]

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.

[Trudy 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]

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]

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]

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! 

[Jerry Raterman]

Hi Matthew, following on from your first response to my question, what is the impact of having 2 issue types in the same hierarchy level?  My company currently has a single Initiative, one for each project.  This initiative is used for portfolio tracking and planning.  Could I add a new Issue Type, called Phase, at the Initiative level?  If I did so, could I then link my Project Phase "Initiative" to my Project initiative?  If I was filtering all of my Initiatives, would the query return all of my projects with Phases as well?  Cheers 

[Trudy Claspill]

Hello @Jerry Raterman 

If you added a new issue type "Phase" to your Issue Type Hierarchy at the same level as Initiative then issues of those two types could not have a parent/child relationship  that the Roadmap would recognize. An issue 's parent must be an issue type from the level directly above it in the hierarchy.

You could use generic issue linking to link the Phase issue to an Initiative issue, but the Roadmap would not see that as a parent and child.

If Phase and Initiative are at the same level then an Epic could have either a Phase or an Initiative as it's parent.

Are you using Jira Cloud or Jira Data Center?

[Matthew Pavlovich]

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]

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

[Karin van Driel]

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

@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. 

[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.