How to designate a Work Item as a Child Work Item within an Epic?

[Genevieve Riffe]

We are trying to add another layer of work placement. We have created an EPIC (called Data Platforms) and within that created Child Work items as 'mini-Epics' to support the overall project. For example, under the EPIC: Data Platforms, there is WORK: Extract Build (as an example).  When creating a Work Item within the 'Create +' feature, we need to have the PARENT label selection to show the WORK: Extract Build and not the EPIC: Data Platforms. How can we accomplish this? Any guidance is much appreciated. Thank you

[Marc -Devoteam- · Accepted solution]

Hi @Genevieve Riffe 

Welcome to the community.

You can't the ootb hierarchy can only have levels above Epic or on the same existing level, but there can't be a level added in between the ootb hierarchy.

[Genevieve Riffe]

Thank you, Marc, for your quick response. It is much appreciated as we are hitting a roadblock. Is this not an option at any level with Jira? Even within the Premium service? Is there a feature or structure that you recommend that would accommodate this? 

[Marc -Devoteam-]

Hi @Genevieve Riffe 

You can rename the Epic work type as suggested by @Trudy Claspill 

Or you would need to revert yourself to 3rd party apps from the marketplace, for custom hierarchy options.

The parent / child relation is only on Epic level, so if this is your wish, best is to rename the Epic work type.

[Trudy Claspill]

Hello @Genevieve Riffe 

Welcome to the Atlassian community.

Natively Jira has just three item hierarchy levels:

Level 1 = Epics
|-- Level 0 = "standard" work item types (Story, Bug, Task, etc.)
    |-- Level -1 = subtask work item types

You cannot insert more levels in between those existing levels. You can add more levels above Level 1 when you have a Premium or Enterprise subscription.

Note that this hierarchy configuration is a global setting that will affect all Company Managed projects. If you make changes to it, all the Company Managed projects are affected.

A guardrail of this hierarchy is that a given work item's parent can come only from the level directly above it. Only work items types at Level 0 may be parents to Subtask types of work items. Only work items at Level 1 may be parents of work items at Level 0.

You can define new work items types at Level 0 and Level -1.

When you define a new work item type at Level 0, in the Work Item Hierarchy you can then move that work item type to a higher level.

There are two options you can consider:

Option 1:

• Use the existing Epic work item type to create items for Data Platforms
• Create children under that as Level 0 work items. This is where you create work items named Extract Builds (your "mini-Epics")
• Create Subtask type work items for the work within those mini-Epics

If you have not worked with subtasks before, there are some limitations on how they appear in agile boards and how they are reported against. 

Option 2:

• Create a new work item type for defining "Data Platforms".
• Add a level above Level 1 (new level = Level 2).
• Move you Data Platforms work item type to Level 2.
• Use the native Epic work item type to create the items that are children of "Data Platforms". This is where you would create your "mini-Epics" items.
• Use the work item types at Level 0 for the child work items under those "mini-Epics"

The native agile boards are not designed to understand a hierarchy that extends above Level 1. To visualize that hierarchy you would need to use the Plans feature.

[Genevieve Riffe]

Thank you, Trudy. Let me pass on this info and circle back to you. 

[Genevieve Riffe]

Dear Trudy.
I will be very honest. This is making my head spin. <insert sad face>

[Trudy Claspill]

If you are new to Jira the many methods it can be customized may feel overwhelming. You might benefit from the free, on-demand training available from the Learning link at the top of the Community pages. There are courses for all knowledge levels, from Essentials courses for beginners to more advanced courses on administration or other focus topics.

The first two sections of this lesson might help you understand the work item hierarchy:

https://community.atlassian.com/learning/lesson/define-work-types-for-company-managed-projects-with-schemes

I might be able to provide a better explanation if you provide some screen images to illustrate what you already have set up. Then I could use the same terminology shown in your images. 

I'll provide some images from my own system to try to help illustrate the Option 1 solution I suggested. This one does not require changing the work item hierarchy.

Here I have created an Epic and set the summary to "Data Platforms"

If I click the "+" button within the Epic I can choose "Create child work item".

When I click that a new row in the Child Work Item area opens, selecting a default work item type that is valid for being a child under an Epic.

I can enter the summary for the child item (i.e. the "mini-Epic") and click the Create button to create that work item.

If I now want to add a child to the "Extract Build" item, I need to open that item.

Within that item I can click the "+" button and select "Create subtask"

Similar to what happened in the Epic this opens section for adding children (subtasks) to the Extract Build item. I can complete the entry by providing a summary and clicking the Create button.

If you are clicking the blue "+Create" button at the very top of the screen you can create only Level 1 and Level 0 types of issues because each of those can be created without requiring a Parent. Subtasks are special because they always must have a parent, so they can be created only as I showed above, from within another item that can be a parent for a subtask.

[Olga Cheban _TitanApps_]

hi @Genevieve Riffe ! Indeed, Jira's native hierarchy can feel a bit inflexible.

as it was already mentioned, you can only change the default hierarchy with Jira Plans (you will need to have Jira Premium or Enterprise to access this feature). then, you will be able to add other hierarchy levels above Epics, such as overarching Initiatives or Themes. but even then, you won't be able to add any new levels below Epic. 

I can suggest a workaround: you can add one more level of hierarchy below Task/Bug/Story by using checklists. 

In this case, checklist items will function as a substitute for Subtasks, Subtasks will be instead of regular tasks in your hierarchy, and so on.

Here's an example: a set of work items with checklists created with the help of our solution, Smart Checklist for Jira.





In fact, checklist items can give you most of the functionality of a Subtask, plus some other useful features.

for example, you can:

- tag responsible people in specific steps
- add deadlines
- set custom statuses for each checklist item
- add links to external resources
- provide extra info in the expandable Details section for each step
- save checklists as templates and reuse them for recurring tasks
- structure your checklist with headers for more convenience:



I hope this helps! Please let me know if you have any questions.

If you decide to go with Jira Plans instead, please see my article Advanced Roadmaps Hierarchy Configuration Guide, it will help you set this up.