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

Ability to create multiple Epic issue types with different names in the same project

NCATS LAB

I have a project that occasionally uses Epics, so I need to keep that alive, but I have a custom issue type that we currently create subtasks under. Due to the nature of our evolving operations, I need to re-build this issue type as an Epic type so that I can nest Issues under it. Currently, simply linking issues is not sufficient, because of how the interface handles these links. I need to be able to edit them from the parent issue, but unlike Epic links and subtasks, there is no way to do this without first going into the task and making the change.

I have found a way to [unlock the custom fields|https://confluence.atlassian.com/jirakb/how-to-unlock-a-locked-field-779158866.html], but unable to modify or create a custom Epic Link Relationship type field.

I have been instructed to do this without purchasing additional add-ons, and am stuck. Any help would be appreciated.

Accepted answers

All comments

Nic Brough -Adaptavist-

Jira Software only supports using Epics as Epics. You can't have others.

There are no add-ons that add other types either. The best you can do is add Portfolio to get other similar grouping functions (but they won't be Epics) or the Structure add-on, which allows you more layers in terms of nesting (but still won't use the Epic functions)

NCATS LAB

Is there a way to nest a full issue type as a child under a parent issue type and get the basic functionality you see with Epic links or Sub-tasks.

Essentially, we are likely going to move to Service Desk, and Customers cannot see Subtasks, so we have to make all of those a full issue, but to do that, we have to nest them as just basic links.

We're going to Service desk to free up user seats and overall reduce cost. I can't purchase another add-on at this time, so was hoping I could do some configuration/database kung-fu to get this to work.

Nic Brough -Adaptavist-

No, the Epic functionality is built to work for Epics. To use non-Epics, you've already got the right idea - use issues and link to them.

NCATS LAB

Nic, thank you for your response.

Is there any way to nest a full issue type as a child under a parent issue type (as a hierarchical relationship) and get the basic functionality you see with Epic links or Sub-tasks.

Jimi Wikman_ex43zi

@NCATS LABcould you describe what you need a bit more?

It sounds like you are trying to have multiple processes into one Jira project and if so there are several ways to manage that.

In Jira an epic is usually a development feature which is then broken down into tasks that connect to User Stories.

Regardless of what you try to do, feature will always be the largest entity in a build and design process. This means that as long as you are working within that process, you should have no problem mapping a parent child relation of the items below the feature level.

You might want to introduce more issue types for design for example to ensure you have your tasks on the right level (Stories often become the actual features and then you have tons of subtasks that are the actual activities, which is usually not a good idea).

If you however want to move above the feature level and move into requirements and business processes, then you either need to extend the hierarchy using Advanced Roadmaps or Structure, or you can build horizontally using a business Jira project and a Development Jira project.

It all depend on what your setup is, so if you describe it a bit more I am sure we can help you sort that out.

NCATS LAB

@Jimi Wikman , Thank you for your suggestions. This was 4 years ago, so I've re-designed my workflows to account for the limitations of Epics.

I still believe that there are many use cases where multiple workflows may be needed for an Epic in a single project - but I have found a way around it.

I would posit that a large number of folks using Jira do not use it only for software development. Therefore, while Jira allows a large amount of customization to the base product, I find it odd that they draw such a firm line on customizing Epics.

Jimi Wikman_ex43zi

I have an upcoming video series for that purpose where I will show how to design all the way from strategic theme down through the build process and then back again in post-golive support

The problem is that people tend to use Jira for things it is not designed for, which is to be a task management system for development. That never works well, unfortunately, so you need to use additional systems for the proper flow.

So you are not alone as you say, there are literally tens of thousands of people doing the same thing and suffer the same way

Stephen Ellwood

@Jimi Wikman the definition of a good product is one which people find uses for that you never intended. From that point of view Jira is an excellent product!! I too find the intransigence regarding Epic customization to be baffling since its so close to being useful but its not. After 40 years of Project management I am still looking for a good project management tool. It makes me cry when I still see people using Excel but I still see this almost daily. Jira could conquer the world, its customers are even telling them how!

Anil Kathane_46xzcy

I have this situation: We are a product team that uses JIRA for development and client implementations.

I understand the concept of epic and this is how we use it: We create epics for large produce deliverables; it encompasses multiple stories, tasks etc. that will go in one release. Stories/Tasks have their workflow that includes activities like development, doc review, unit testing, etc. Our releases however are at epic level (we only release entire epics, never single user stories). So the release activities are all part of Epic workflow. And the process works quite well. So far so good.

Then we have a maintenance/KTLO epic, that we use for routine maintenance work items like bug fixes, etc. that are not part of regular development process. This epic again does not follow the developmental workflow since the bugs are released individually on need basis, this epics is only to combine data for reporting.

Now, we need to start working on client implementations as well. Each client implementation would have its own stories and tasks (mainly tasks, occasional development stories). I believe it would be appropriate to create such implementations as Epics, so we can club all tasks and stories underneath those. But such an epic won't follow the same workflow as Development Epic. I am struggling how to create a different workflow for such cases, since JIRA doesn't allow that.

Any thoughts on how to manage these different workflows for the epics?

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software

epic

issue-type

epic-link