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.
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.
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:
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.
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
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.
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 !!
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.
Absolutely. Is there an issue to vote on??
There was, but it was closed "won't fix" years ago.
@Nic Brough -Adaptavist-Could you link to that ticket?
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.
can't we create the epic level properties for an custom issue type from database side.
No. Because most of the functionality is in the code, not the data.
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 )
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.
It looks like you're new here. Sign in or register to get started.
