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

Impact of Jira Issue-type hierarchy change

HQRAZAHS

Hello Folks,

I hope everyone is doing well. My project is using a wrong issue type hierarchy and I am appointed to make a correction in it.

Currently used - Initiative->Feature->Epic->Task/Bug/Story->Subtask
Revised version 1 - Initiative->Epic->Feature/Task/Bug/Story->Subtask
Revised version 2 - Initiative->Epic->Feature->Task/Bug/Story->Subtask

Question 1: Out of the 2 versions above, which one is convenient to use?
Question 2: If the change is made, what will be the impact? I have seen couple of articles and that stated the parent-child relation between Initiative, Epic and Feature will be lost. I understand that.
But apart from this impact will there be any other impact like impact in automations/filters/confluence configurations etc. ?

Thanks in advance.
Ahsan

Accepted answers

All comments

Gor Greyan

Hi @HQRAZAHS

1. Recommended Hierarchy is version 2: it provides:

Clearer structure and aligns with SAFe.
Better for reporting and roll-ups.
Avoids mixing direct Story/Feature under Epic.

2. Impacts of Change:

Parent-child links lost (Initiative–Epic–Feature).
Automations using parent/epic link fields will break.
JQL filters & boards need updates.
Advanced Roadmaps hierarchy reconfiguration required.
Confluence macros/reports may show missing data.
Integrations/APIs referencing the old hierarchy will fail.
Historical reports may show gaps or incorrect roll-ups.

Tomislav Tobijas

Hi @HQRAZAHS ,

I'd say convenience depends on your reporting, planning, and parent-child relationship needs, but if you want Features to group Stories/Tasks, version #2 is probably more robust.

Also, a good question is why the current config. is 'wrong'? Looking at some Atlassian recommendations, this structure is fine. Even demo Atlassian sites have it configured this way:

Level	Level name	Jira work types
3	Initiative	Initiative
2	Project/Feature	Campaign Project Feature
1	Epic	Epic Risk Deliverable
0	Story
-1	Subtask

⚠️ Note that you cannot move Epic from level 1; you could rename the default Epic and then use a custom one on levels above/below, but I wouldn't say that's recommended.

As for the impact of changes, what Gor said is pretty much it. It's recommended to review everything and perform some kind of bulk updates before making the 'switch' in hierarchy.

Cheers,
Tobi

HQRAZAHS

@Gor Greyan @Tomislav Tobijas True that the 2nd version is more convenient and robust. But how do I configure it? In my test environment Jira, I tried to configure the 2nd version but I cannot do this. Whenever I create a new level it always goes to the top level, not at the lower level. Moreover, the worktype Epic is non-removable from level 1. Even if I do some tweaks by renaming the levels, the functionality of Epic will always be at the level 1.
On the other hand, 1st version is easily possible, I simply need to delete Feature from my existing hierarchy and it will automatically go the the level 0 (below Epic).

@Tomislav Tobijas To answer your question, AFAIK in the SAFe recommended hierarchy, Feature cannot be the parent of Epic, it should be vice-versa. Correct me if I am wrong here.

Gor Greyan

Dear @HQRAZAHS

- Yes, the Epic issue type is locked at Level 1 in Jira and can’t be moved below another issue type like Feature. Any new hierarchy level you create (Initiative, Capability) is always placed above Epic.
- The structure of Version 2 is technically possible in native Jira if it is Premium or Cloud. However, Version 1 works — you just need to remove the Feature from the current hierarchy so it becomes a normal issue type under Epic.

I can see that you are using Premium.

You can check these documents for the custom hierarchy:
https://community.atlassian.com/forums/App-Central-articles/Advanced-Roadmaps-Hierarchy-Configuration-Guide-2025/ba-p/3031309

https://confluence.atlassian.com/advancedroadmapsserver0329/configuring-initiatives-and-other-hierarchy-levels-1021218664.html

https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/

https://support.atlassian.com/jira-software-cloud/docs/configure-custom-hierarchy-levels-in-advanced-roadmaps/

HQRAZAHS

ok let me check these links. Thanks for the support @Gor Greyan

Gor Greyan

Dear @HQRAZAHS
Let me know if you need further assistance.

HQRAZAHS

Hey @Gor Greyan I checked these links but nowhere I could see that a Feature can be placed between Epic and task/story/bug (version 2). All the links talks about adding new hierarchy levels and matching them with the issue types.

The first link though talks about a plugin or a 3rd party integration tool but the team is currently not in favor of spending to purchase any license/tools.

Tomislav Tobijas

@HQRAZAHS, as for this

To answer your question, AFAIK in the SAFe recommended hierarchy, Feature cannot be the parent of Epic, it should be vice-versa. Correct me if I am wrong here.

True... There's this (a bit older) thread that might give some additional insights: Why is JIRA issue hierarchy different from Scaled Agile Framework hierarchy?

But yeah - you'll have to weigh your options here and see how to proceed.

In the end, when aligning with SAFe, using consistent terminology is important so that everyone (business leadership, teams, metrics/reporting) has a common understanding.

HQRAZAHS

Thanks for the suggestions @Tomislav Tobijas . Let me see what suits best for our projects will go accordingly.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud