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

Issue type hierarchy is wrong (SOLVED)

JSWizards Development

It seems impossible to create a correct issue type hierarchy in [ cogwheel > issue type hierarchy ]. Epics are mandatory as level 1 and it's impossible to create sub-levels. I met the same problem in plans and in the standard project view (as Premium & Admin user) .

I want this hierarchy :
Themes > Epics > Features > Stories > Tasks > Sub-Tasks | Bugs

This means that:
- sub-tasks or bugs must have tasks as parents.
- tasks must have stories as parents.
- stories must have features as parents
- features must have epics as parents
- epics must have themes as parents

Configuration Use Cases i tried :

level 5 - Sub-Task | Bug
level 4 - Task
level 3 - Story
level 2 - Feature
level 1 - Epic
level 0 - "All other standard issue types"
level-1 - "All sub-task issue types"
Problem : Parent set-up is reversed. Epics parents are features instead of themes. Features parents are stories instead of epics, and so on. Themes cannot be set.

level 5 - Feature
level 4 - Story
level 3 - Task
level 2 - Sub-task | Bug
level 1 - Epic
level 0 - "All other standard issue types"
level-1 - "All sub-task issue types"
Problem : Ok, but epics are the most granular (bottom) elements. This completely eliminates the purpose of the "Timeline" view in project planning. Themes cannot be set as parents of epics and Epics can't be set as parents of features.

level 1 - Epic
level 0 - "All other standard issue types"
level-1 - "All sub-task issue types"
Problem : Removing all levels only allows having epics as parents, which is not interesting as the project I prepare will have too many tasks.

Thanks for reading me out.

Accepted answers

Robert Wen_Cprime_

Hello @JSWizards Development ! Welcome to the Atlassian Community!

You won't get the hierarchy that you want now, out-of-the-box. You'll probably get closer when Atlassian allows Epics to be renamed to anything else.

I think you'll have better luck working with a Marketplace app like Structure.

All comments

Robert Wen_Cprime_

Hello @JSWizards Development ! Welcome to the Atlassian Community!

You won't get the hierarchy that you want now, out-of-the-box. You'll probably get closer when Atlassian allows Epics to be renamed to anything else.

I think you'll have better luck working with a Marketplace app like Structure.

Trudy P Claspill

Hello @JSWizards Development

Welcome to the Atlassian community.

Jira has a core 3-level hierarchy initially defined as

(1) Epic
|-- (0) standard level issues (i.e. Bug, Story, Task)
    |-- (-1) subtask level issues

With the premium subscription you can add levels above Epic in the hierarchy, but only above Epic. You can't add levels below Epic:

(3) Issue Type A
|-- (2) Issue Type B
    |-- (1) Epic
        |-- (0) standard level issue types
            |-- (-1) subtask level issue types

You can create new issue types at the Standard level, and then move those issue types up to associate them to levels 1 and higher.

You can also create additional issue type at the Subtask level, but they cannot be moved to another level.

In the Jira hierarchy an issue's parent can be from only the level directly above it.

So, let's look at your desired hierarchy.

Themes > Epics > Features > Stories > Tasks > Sub-Tasks | Bugs

(4) Theme
|-- (3) Epic
    |-- (2) Feature
        |-- (1) Story
            |-- (0) Task
                |-- (-1) Sub-task or Bug

-1. You can't "move" the Bug issue to the lowest level. You can, however, make another Sub-task type of issue and call it something like "Bug Sub-task".

0. "Task" is a standard level issue type. In order for it to be made a child of a Story (another standard level issue type), Story has to be moved up to level 1 where Epic initially exists. Standard issue types moved to that level are not treated like "epics" by the built in Jira Epic functionality. They won't show up in the Epics panel in backlogs. They won't be available in the Epics Burndown reports. When last I checked, that functionality would be applied only to the original built in issue that was named Epic. It is possible to change the name of the issue currently called "Epic" to something else (that is not used as the name of another issue type) but I have seen that name change have a negative affect on Epic-specific functionality.

1. This is the level where the built in Epic issue type is normally located. See comments about Story and renaming the built in Epic issue type in my last paragraph.

2. You can create a new standard level issue type named Feature, and then move that issue type to this level.

3. At this level you have indicated "Epic". You can't move the built-in Epic issue to a different level, so you can't move it to level 3. You could create another standard level issue named something else (i.e. Epic2) and move that to this level, just like you could do for Feature.

4. See my comment about Feature.

That is what is possible within the constraints of Jira's issue hierarchy functionality and how Jira will automatically recognize parent and child issues.

Besides that, you could use the generic Issue Linking functionality to artificially create relationships between issue and call them "parent of/child of", but Jira would not do anything special based on that. Advanced Roadmaps Plans would not see those as hierarchical relationships.

Beyond that as @Robert Wen_Cprime_ suggested you would need to explore the use of a third party app for customizing the hierarchy.

Andreas Haaken (APTIS)

Agree on @Trudy P Claspill , but you will never be able to customize the basic Level 1 (Epic) and Level 0 (Story or anything not in another level) to something that works with the default boards like Kanban and Scrum.

So the tradeoff to use a personal adjusted hierarchy is that Jira Software won´t work as expected. So: if you are in definition phase and have the ability to define your levels: don´t touch the default setup up to Epics.

If this is a hard requirement, you cannot use huge parts of the agile tools in Jira.

This seems to be quite odd, but as a result of a gronw system, this is actually really hardcoded into Jira (like the fact that an issue with a given resolution counts as done, regardless to the actual assigned status )

So my suggestion:

Think about a hierarchy that is set to your need ABOVE Epics.

Even if you use other tools to display hierarchies that are customized, like Structure, Big Picture or Epic Sum Up that will not change the hard dependency to the usage of Boards, Timeline etc.

Hope that helps and saves time

John Funk

Hi @JSWizards Development - Welcome to the Atlassian Community!

You will not be able to have Tasks as children of Stories because they are both Level 1 issue types. Nor should you do that - that is not standard Agile practice. You can have both Tasks and Stories, but they are siblings and children under the Features.

To get Features and Epics like that, in the hierarchy you would rename Epics to Features, and then actually change the name of the Epic issue type to Features as well. But his will modify all of your existing Epics, so you might not want to do that.

Then you would create a new Issue Type called Epics and place that at Level 2. You have to go this route (we were instructed by Atlassian for this method) as you can't just drag the Epic issue type up to a new level.

Then you could add your Themes issue type as a Level 3.

Using the Parent field will work across all of the Levels then.

JSWizards Development

Hello @Robert Wen_Cprime_

I investigated into how the "Structure" app works and indeed, it does fit my needs well. I've been able to add the whole hierarchy of levels I wanted. I've also used the included "Structure.Gantt" app, which allows me to create a Timeline for Tasks, which updates other levels as well.

I have tried Jira plans too. Even though they are more sophisticated than the standard Jira project plan, I had to use Structure to get the sub-Epics hierarchy.

Thank you a lot for your help!

JSWizards Development

Hi @John Funk ,

I've followed your advice on Agile practice, but I still wanted to achieve some form of visual hierarchy so I decided to use the following parent-child principles :

Themes have : Epics as children.
Epics have : Features, User Stories, Technical Debts as children.
Features have : Tasks, User Stories, Bugs, Technical Debt, Spikes as children.
User Stories have : Tasks, Bugs, Technical Debts, Spikes as children.
Tasks have : Sub-Tasks
Sub-Tasks, Bugs, Technical Debts have : no children.

This lead me to put the following elements acceptance at each level of the "Structure" app :

Level 1: Themes
Level 2: Epics
Level 3: Features, User Stories, Technical Debts
Level 4: Tasks, User Stories, Bugs, Technical Debt, Spikes
Level 5: Tasks, Bugs, Spikes, Technical Debts
Level 6: Sub-Tasks

I've tried this and got great results.

Thank you for your help!

JSWizards Development

Hello @Trudy P Claspill and @Andreas Haaken (APTIS) ,

Thank you both for your insights on Jira's issue type hierarchy and the implications of customizing it beyond the default levels. This clarifies the constraints within Jira and the impact of renaming or moving issue types, especially with Epic-specific functionalities and agile tool compatibility.

Based on the encountered limitiations, I've decided to leverage the "Structure" app for my project. My project is still at the start-phase for management and I can avoid impacting the default setup up to Epics. In the app, I put a "parent of" relationship, which modified the tasks flawlessly.

I appreciate your guidance and suggestions, which clarified how Jira functions in practice.

Thank you for your help!

John Funk

Glad that is working for you.

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

issue-type

levels

level