Jira Work type hierarchy

[Scott McDonald]

We have a request to modify the Work type hierarchy.

In summary the team is asking to add a hierarchy level for features between Epic and Story.

We want to know first is this possible, and second what would this change impact? (Boards, etc)

L4- Initiative

L3 - Solution

L2 - Epic

L1 - Feature

L0 – Story (All other Work Types)

[Viktoriia Golovtseva _TitanApps_ · Accepted solution]

Hi @Scott McDonald 

You can:

• Rename hierarchy level names (e.g. rename “Epic” level to “Feature”).

• Add extra levels above the Epic level if you’re on Jira Cloud Premium / Enterprise (for things like Initiative, Solution, etc.). 

You cannot currently insert a new level between Epic (L1) and Story (L0). That’s a long-standing limitation, and Atlassian have confirmed that even with the newer work type hierarchy, levels can only be added above Epic.

So this exact stack:

L4 Initiative
L3 Solution
L2 Epic
L1 Feature
L0 Story

…is not possible as a strict “Feature between Epic and Story” hierarchy.

However, you can achieve  this by flipping the naming:

• Rename the Epic level (L1) to “Feature” and make your Feature issue type live there.

• Add additional levels above it for Epic, Solution, Initiative:

  • L3 – Initiative (custom level above Epic)

  • L2 – Solution (custom level above Epic)

  • L1 – Feature (Epic level, renamed)

  • L0 – Story / Task / Bug

Functionally you’ll get:

Initiative → Solution → Feature → Stories/Tasks → Sub-tasks

…which is usually what teams want when they say “Feature between Epic and Story”.

Some key impacts to be aware of:

a) It’s global for company-managed projects
The work type hierarchy is configured at the Jira site level. Changing levels or moving work types affects all company-managed projects that use that scheme, not just one team. 

b) Parent/child links can break when you change levels
Atlassian explicitly warns that changing the work type hierarchy may break existing parent-child relationships. If you move work types between levels or add new ones, some items may lose their parent and need to be re-linked. 

Expect to review and potentially fix:

• Parent / child links (Epics ↔ Stories, Initiative ↔ Epic/Feature, etc.)

• Any automation rules that rely on “parent” or on specific issue types

c) Boards & backlogs

• Scrum/Kanban boards are still centered around standard level (L0) issues for sprints/backlog.

• “Epic” level (whatever you rename it to, e.g. Feature) appears in the Epics panel

• Any new levels above Epic (Initiative, Solution, etc.) don’t get special treatment on boards. They behave like normal issues and will only appear if your board filter includes them; there’s no dedicated “Initiative” panel in the backlog. 

So, after the change:

• Your backlog “Epics” panel will effectively become a “Features” panel.

• Initiatives / Solutions will mostly surface in Plans (Advanced Roadmaps) and in JQL/dashboard reports, not in the daily sprint board UI.

Plan a short clean-up phase after the hierarchy change.

Some additional thoughts: 

You mentioned “L0 – Story (All other Work Types)”. That’s aligned with Jira’s default idea of “standard work” – Stories, Tasks, Bugs, etc. all live at the same level and can be parents of sub-tasks. 

If your team is mostly looking for more organization below a Story (lots of tiny subtasks, checklists of steps, etc.), you don’t necessarily need more hierarchy levels. You can keep the hierarchy simple and use a checklist app for the fine-grained work.

If you find that Stories or Features are getting “subtask-heavy” and the backlog becomes noisy, one good alternative is to keep the hierarchy shallow and track the detailed steps in a checklist.

Smart Checklist for Jira (full disclosure: I work with the team behind it) lets you:

• Add one or multiple checklists directly to a Story, Feature, or sub-task.

• Break work into small, trackable items (with status, assignee, due date, and comments) without creating dozens of actual sub-task issues. 

• Use templates for recurring workflows (e.g. “Feature readiness”, “Release checklist”, “Definition of Done”).

This approach gives you a practical structure like:

Initiative → Solution → Feature → Story → Checklist 

In this case instead of going deeper and deeper with more issue types and extra sub-task levels. It keeps boards cleaner, makes reporting easier, and still gives teams a very detailed view of what needs to be done on each work item.

[Felipe Justino · Accepted solution]

Hi @Scott McDonald 

I’ve worked with similar requests before, and here’s what I can share based on experience.
You can add an extra hierarchy level between Epic and Story, but it depends on whether your projects use Company-Managed or Team-Managed settings. In company-managed projects, the hierarchy is controlled globally, so adding a new level affects every project that uses that hierarchy. In team-managed projects, it’s not possible to insert new hierarchy levels.

Before creating a new level, I always recommend evaluating whether the current hierarchy is truly insufficient. Many teams solve this need using Epics + Components, custom fields, or issue linking, without adding structure that may become hard to maintain later.

If you do proceed, the main impacts are:

• Reporting: Dashboards, roadmaps, and any hierarchy-based reports may need reconfiguration to recognize the new level.
  Issue linking behavior: Teams must adopt new standards for how issues roll up into the new level.
• Workflows and fields: If you create a new issue type (like “Feature”), take time to align fields, screens, and workflows so it fits naturally into existing processes.
• Change management: Users will need clarity on when to use the new type, otherwise the hierarchy gets messy quickly.

My suggestion is: only introduce a new hierarchy level if the team truly needs visibility above the epic level and if this structure will be consistently adopted across projects. Otherwise, simpler alternatives might deliver the same result with less overhead.

[Scott McDonald]

@Felipe Justino thank you

We are trying to create brand new work types for this team and then set them to the hierarchy levels they would like.  Allowing them to have their own levels without effecting others.

If we remove the old work types from their scheme, will Jira automatically ask us to map the existing ticket to a new work type?

[Trudy Claspill]

Hello @Scott McDonald 

First I want to mention that modifying the hierarchy in this manner is available only if you have a Premium or Enterprise subscription.

It is not possible to truly "insert" a level between the current L1-Epic and L0-standard items. But here is what you can do.

1. Rename the current work item type "Epic" to "Feature". At that point all the behaviour and functionality associated with the native epic type is applied to the "Feature" type.

2. Create a new standard work item type named "Epic". To avoid confusion you might want to give it a slightly different name, though, so that your users don't expect the original epic functionality to apply to this new work item type. You have to create a new work item type for this because it is not possible to move the native Epic type to a different level.

3. In the Work Item Hierarchy configuration screen add a new level above L1 and add your new "epic" item type to that new level.

Repeat steps 2 and 3 for Solution and Initiative, adding a level above L2 for Solution and then above L3 for Initiative.

Work Item names are global in Company Managed projects. Changing the name of the current Epic item to Feature will affect all Company Managed projects that use that issue type. It also changes the name of the "Epics" panel and the Group By and Filter options that previously said "Epic".

Changing the Work Item Hierarchy is a global impact for Company Managed projects. Adding new item types and new levels for L2, L3, and L4 will only impact projects that use those work item types. If the projects don't use those work item types then they will not be affected.

If those work item types already exist and are in use and you change the level at which they reside, that will affect any project already using them. It would also break parent/child relationships that involved those work items types.

[Scott McDonald]

@Trudy Claspill Thank you

We are trying to create brand new work types for this team and then set them to the hierarchy levels they would like.  Allowing them to have their own levels without effecting others.

If we remove the old work types from their scheme, will Jira automatically ask us to map the existing ticket to a new work type?

[Trudy Claspill]

Yes, and you will only be able to select from the types available in the Work Item Type Scheme for that project. So you need to add the new types to the scheme first.

Please note that while you could add a brand new work item type named "Feature" to L1, it will not be handled in the same manner as the native Epic type. The Epic panel will not be renamed to Features and contain the Features item types. The native Epic functionality applies only to the native work item originally named Epic.

From the perspective of Jira that new item named "Feature" as well as "Initiative" and "Solution" and the new work item type you put a L2 will be treated like L0 items in the Backlog and Board displays. The only place that the hierarchy is visible is in List tab and in Plans.

[Walter Buggenhout]

Hi @Scott McDonald,

In short:

• Rename your existing epic work type and hierarchy level to Feature.  
• Add a new work type and call it Epic. Add it to the work hierarchy above the feature formerly known as epic.
• Repeat for Solution and Initiative

Just keep in mind that this update will be applied across your entire Jira instance.

Hope this helps!