How do I create a custom Epic issue type?

[Vince Butera]

I'd like to add an issue type with the equivalent hierarchy as an Epic but call it Theme. I don't see how this is possible.

[Earl McCutcheon · Accepted solution]

Hello all,

I had already added the following comment in a reply in one of the other answers on this thread, and I just wanted to add the info as a separate Answer as to add in some additional visibility for the information:

Reviewing this thread the default behavior in Jira, as mentioned a few times is designed to be locked in the hierarchy of Epic > Issue > sub-task, with options like adding in Portfolio for Jira or Jira Align to put additional "initiative" layers above the epic to expand the hierarchies further.

While Portfolio or Align would solve some of the issues it is creating layers in an alternate direction than discussed here, and would require adjusting process to align with the design of the tool and remapping the issue type layers and naming conventions in your local processes to adapt to the intended applications layout.

An alternative for the use case described above and what I believe would be a better tool for this scenario would be to look at the add-on app Structure, which modifies the default behavior allowing you to manage alternative hierarchies ad-hoc and may fit the needs of your organization, and would be a good alternative to check out.

Also to relay the reply from @Philip Heijkoop _ALM Works_   as well, as there is some really good additional details in his  comment here:

• https://community.atlassian.com/t5/Jira-questions/Re-Re-How-do-I-create-a-custom-Epic-issue-type/qaq-p/1362265/comment-id/422186#M422186

Philip_Heijkoop__ALM_Works_

Building on Earl's comments, this is a common predicament we see people run into. It's particularly common when people are coming from a hierarchy naming convention that doesn't completely jive with Jira's.

If you're interested, I wrote an article describing some of the considerations to keep in mind here, where I compare the SAFe hierarchy of Epic-Feature-Story to Atlassian's recommended Initiative-Epic-Story, but the thinking is obviously universal.

It's important to realize that Jira does things a certain way, and it does so for good reason (even if that isn't always apparent at the outset). Sometimes deviating from that is worth the extra effort, but it should be an explicit decision that is well understood. Going outside that means you can't build on years and countless teams' experience for effective Agile project management.

Regards,
Earl

[Abhishek Kaushik]

There should be option to allow JIRA admins to add a new field like Epic. Simple and important business case is, As a product owner I want to create one more level "theme" between Epic and User Stories to manage my backlog better. Pls let me solution  for this ?

This is very important for product owners, dont understand why Atlassian dont work on it and provide a solution? This should not be that tough !!

[John Gill]

It'd be great if we just had a issue hierarchy schema. 

Epic
▼
▼
Theme
▼
▼
Issue
▼
▼
Sub-task 

And we could mix and match, as we'd like, easily. 

They are getting closer to this, but it's still very difficult to even approximate this solution. 

I'm sure we aren't alone in this idea. Not everything can be condensed into Epic >> Issue >> Subtask, and I don't think one extra layer makes us wrong. 

[Joe ALVES]

I really need too this possibilty too , very very important in BIG TRANSVERSAL Projects.
We can do this on MIcrosoft VS tools ... (i know , i know ;))

[Nic Brough -Adaptavist-]

Nope, you don't "need" to do it, you've just landed somewhere that people who want to do "waterfall" without admitting that it doesn't work.

I love the use of "Transversal", it screams failure. 

[Earl McCutcheon]

Hello all,

Reviewing this thread the default behavior in Jira, as mentioned a few times is designed to be locked in the hierarchy of Epic > Issue > sub-task, with options like adding in Portfolio for Jira or Jira Align to put additional "initiative" layers above the epic to expand the hierarchies further.

While Portfolio or Align would solve some of the issues it is creating layers in an alternate direction than discussed here, and would require adjusting process to align with the design of the tool and remapping the issue type layers and naming conventions in your local processes to adapt to the intended applications layout.

An alternative for the use case described above and what I believe would be a better tool for this scenario would be to look at the add-on app Structure, which modifies the default behavior allowing you to manage alternative hierarchies ad-hoc and may fit the needs of your organization, and would be a good alternative to check out.

Regards,
Earl

[Philip Heijkoop _ALM Works_]

Building on Earl's comments, this is a common predicament we see people run into. It's particularly common when people are coming from a hierarchy naming convention that doesn't completely jive with Jira's.

If you're interested, I wrote an article describing some of the considerations to keep in mind here, where I compare the SAFe hierarchy of Epic-Feature-Story to Atlassian's recommended Initiative-Epic-Story, but the thinking is obviously universal.

It's important to realize that Jira does things a certain way, and it does so for good reason (even if that isn't always apparent at the outset). Sometimes deviating from that is worth the extra effort, but it should be an explicit decision that is well understood. Going outside that means you can't build on years and countless teams' experience for effective Agile project management.

[Steven F Behnke]

It's not possible, I think is the most straight-forward answer.

The field Epic Name, Epic Link, Epic Color, and Epic Status are add-on fields (NOT custom fields, they are add-on fields) that are tied to the Epic Issue Type upon JIRA Agile installation. This is why they only show up on the Epic Issue Type, this is why they do not show up on others. Additionally, the Epic Link functionality, along with Scrumboard Agile functionality, are specifically tied to the issue type.

As far as I know, you cannot simply add a new issue type to extend this functionality. 

[Chethan GR]

can't we create the epic level properties for an custom issue type from database side.

[Nic Brough -Adaptavist-]

No.  Because most of the functionality is in the code, not the data.

[George Lewis]

I'd like to add an even simpler oversight from Atlassian - being able to create addtional Epic issue types. If they see fit that we can create our own issues with different names. workflows etc, why do they think that all these issue types can just be bundled under one epic type.

[Bernd]

Absolutely. Is there an issue to vote on??

[Nic Brough -Adaptavist-]

There was, but it was closed "won't fix" years ago.

[Grayson Bishop]

@Nic Brough -Adaptavist-Could you link to that ticket?

[Nic Brough -Adaptavist-]

https://jira.atlassian.com/browse/JSWSERVER-7203 - was closed years ago, but actually, re-opened a couple of weeks back to gather more interest.  Worth hitting vote on it.

[Nidhi Shah]

@Nic Brough -Adaptavist- So, there is no way in current scenario (in JIRA v7.6.2) where you can create new (your own) issue type and make it behave like an Epic Issue type? 

[Nic Brough -Adaptavist-]

Exactly what Steven said, and I've pointed out there's no change so far.

[Jacob]

Ditto here.  I don't want to explain to users what 'Epic' is our why they would pick that as an issue type.

[Terence Rhoda]

I have the same issue. I want to create an additional issue type 'iterations' that behaves  the same as an epic. We want to use Epics for sub-projects and the iterations for .... well iterations within that sub projects. :)

[Nic Brough -Adaptavist-]

No (significant) updates on the request linked to above.  It's pretty much "one type is epic, go get Portfolio or Align if you want more layers"

[Gira Mundo]

In my case, I don’t need a hierarchy, I need only to create an issue type that, like an epic, enables to visualize several other issues (tasks) that must be done to achieve the goal. Of course, I can use the epic use, but it is not convenient for two reasons:
1. It sounds strange for people that will use it.
2. We need to distinguish that issue type from real epics used in several agile projects
So, it be very useful to have a new “like epic” issue type-

[Nic Brough -Adaptavist-]

See above for why you can't do this, and won't be able to in the future

[ChrisR]

where is the no like!

[Nic Brough -Adaptavist-]

@ChrisR- "dislike" was available on the previous community platform and was seen as counter-productive.  We wanted people to feel welcome and get them engaged.  When it was used correctly (as in "this is a bad thing" or "I genuinely don't like your post because") it was ok. But most were being used to attack individuals, and the few that were genuine did not get seen by Atlassian - disliking a post saying "you can't do this (yet)" on the community does not have any way to become a vote for a feature request in Jira.

But the facts were that it was abused and gamed in various ways, so one of the first "community leaders" meetings quickly concluded that down-votes are not useful.  We decided that the best option was to push people over to vote for features in https://jira.atlassian.com as that does get counted.