How do I use Issue Types at the Epic level in Jira Premium

[Paddy Walsh]

I am trialing Jira Premium and one of the features I really want to use is having extra issue types at the Epic level.

So I have created a new issue type called 'Problem' at the Epic level in the issue herarchy - the idea being I can have child Bugs (we need a bug fix per supported release).

However:-

1) The new issue type does not have the 'create child issue' icon on it - just create sub-task. But if it is the same level as Epic surely it should have child issues (like Story or Bug) and not sub-tasks. It does not seem to be at the same level as Epic at all?

2) I am unclear about how to link a Bug (child) to the new Problem (parent) issue type. I have added the Parent Link field to Bug and it seems to only allow Problems to be selected - but what if I add more Epic level issue types - how can I validate that the parent is the correct issue type (I usually use JWT for such validations).??

[Mark Segall · Accepted solution]

Hi @Paddy Walsh - Short answer is that there is no equivalent to Epic in Jira.  Jira Software Premium offers the ability to create a hierarchy ABOVE the Epic.  This enables organizations to tie tactical work up to strategic objectives.  I hope this helps clear things up.

As for your challenge.  What is your reason for wanting to create an issue type that is the same as Epic?  Is it simply nomenclature?  You could create logical separation between traditional Epics and Epics serving as "Problems" by leveraging a component.  Create a component called "Problem" and tag Epics accordingly.  Then you can query for Epics where they have that component.

I hope this helps.

[Paddy Walsh]

Hi Mark,

Thanks for the answer.

Jira Premium clearly says you can create new issue types at the same level of hierarchy as Epic (which I have done) but I fail to see how they are at the same level if they behave exactly like issue types at level 0 (base level)? They are not really at Epic level at all. I recommended that we pay for Jira Premium on the basis we could do this but it is not of any use as it stands.

The reason for having another issue type at the Epic level is because they have totally different workflows and I otherwise have to define different types of Epic with different conditional behaviour in the child issue types which is very messy. I was hoping we could have a clean separation. I cannot use component as we are already using that for its actual purpose in both Bugs and Features.

[Paddy Walsh]

In addition, I have read that Jira plans to merge Epic Link and Parent Link into a single Parent field in the future. In this case, a level 0 issue could have a parent that is an epic or something else (at level 1). Or am I misunderstanding?

[Mark Segall]

Hi @Paddy Walsh - Correct they may be at the same level of an Epic, but that is only in the context of an Advanced Roadmap.  It still comes back to there only being one true Epic in the system. 

As for solving your issue, I understand that you're trying to get another Epic-level field so you can have two issues at the same level with different workflows.  The problem is that you simply cannot replicate Epic functionality:

• Show it in the Epic Panel
• Create child issues directly from it
• Leverate epic coloring

How disparate are the workflows between the two issue types?  Perhaps you could still leverage Epic for everything, but incorporate workflow conditions based upon some other mechanism (custom field?) since you're rightfully using components for another purpose.

In addition, I have read that Jira plans to merge Epic Link and Parent Link into a single Parent field in the future. In this case, a level 0 issue could have a parent that is an epic or something else (at level 1). Or am I misunderstanding?

Yes, they've had that plan in the works for a while but it's more of a consolidation thing.  It's important to understand that Scrum boards and Advanced Roadmaps had humble roots as a maketplace apps before Atlassian acquired them.  Marketplace apps oftentimes need to leverage custom fields resulting in the origins of fields like "Epic Link" and "Parent Link" respectively.  Atlassian has been steadily trying to better integrate these acquisitions into Jira and consolidating these fields into the Parent field which has been a system field for a long time.  This will make it so people no longer need to think about whether they use Parent, Parent Link, or Epic Link in their queries.

Sorry for the verbose history lesson.  Just wanted to add context to what you read.  I hope it helps.

[John Partington]

I agree, its really frustrating that the functionality behind Epics can not be used by multiple issue types.
We'd like to manage the refinement of groups of Storys using an issue called "Requirement" that behaves like an Epic issue type and also manage the delivery of development work using an issue called "New Feature" that behaves like an Epic issue type.

If Epic is used for both purposes:

1) its confusing

2) its not possible to define a different workflow for a Requirement & for a New Feature. And they are significantly different.

Scrum functionality is severely limited if Epics are not used for groups of issues, in fact they are almost mandatory if you dont want to spend hours on managing and reporting on sprints.

[Joseph Donal Wolf]

We're trying the same (i.e. creating issuetypes at the Epic level) and it works in many ways (in terms of being able to add Tasks as child items of these new types and see them grouped accordingly in Jira boards), but what is odd is that on the new issue AND in the Backlog, you can certainly update the color of the item (e.g. to yellow, green, red... etc.), but on the Board view all of the Tasks that are child items of these new types show the parent as a "Light Purple" color label on the Task card.

Is there any way to remedy this?