Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Can you have an 'issue hierarchy scheme'


Once a business has Jira Premium and has hierarchy beyond Epics (we want Story - Feature - Epic confusingly).  Can there be applied selectively across the Jira instance (like a scheme is) or is it a one size fits all for the whole instance? 

Also, when we transfer from Story - Epic to Story - Feature - Epic is Jira Premium able to keep the mappings that are there? We would want to swap all 'old epics' to be called features, then build 'new epics' above these.  

2 answers

2 accepted

2 votes
Answer accepted

Welcome to the Atlassian Community!

It's one hierarchy across the business - one of the big things about scaling upwards and planning is that all teams need to be doing some things in the same way, otherwise you simply can't work with them together.  Hierarchy is one of them.

So, I imagine you've probably got the standard hierarchy of 

  • Epic
  • Issue
  • Sub-task

And you imply you are looking to add "Feature" in between Epic and Issue?  Then you are thinking you would convert all of your Epics to Features?

I would do it slightly differently.  Rename Epic to Feature, then create a new Epic at the level above the new-Feature/ex-Epic.

This way, you won't be disrupting your existing data or having to do large bulk edits.

Cheers for the advice, and good pointer on 'feature insertion' thanks

1 vote
Answer accepted

Hi, @Niall McPherson. Welcome to the community 👋

For an alternative opinion, I've seen many organizations use different hierarchies across different Jira teams/projects by using an Atlassian Marketplace add-on. In other words, Jira out of the box does not support this.

That said, @Nic Brough -Adaptavist- is right in that life is simpler if everyone does things the same way in Jira.

Unfortunately, for many organizations, getting everyone to do things the same way simply won't fly. In fact, here's an Atlassian Community article about one such company:

Interview With an Expert: How BlueCat Networks Uses Structure for Jira to Tame Fast-Scaling Work

The add-on in question, Structure, comes from the company that employs me — but there are other Jira apps that can do this, too.  Structure just happens to be one of the more popular ones.

Anyways, some companies need that flexibility. They want to Jira to adapt to the way they work, versus adapt the way the work to Jira. And there's enough of them out there that my company, and the others, can sell enough software and make money doing it. 

As @Kelly Arrey, the expert cited in the article above once said to me: "People have to decide if they want to be dogmatists or agilists, because agilists put people before tools."

Hope this helps,


I like the logic but i'm not in a place to get the tanker to turn in that direction unfortunately.  We are on Jira basic fighting for premium so this is 10 steps too far right now.  I'll keep it in mind thou for the future.  

Hi @Niall McPherson

We use Structure to implement a deeper issue hierarchy without Jira Premium.  Our hierarchy looks like this:

Features -> Goals -> Epics -> Stories

We use a custom issue link type we call "contains <-> belongs to" (the parent issue "contains" the child issue, the child issue "belongs to" the parent issue).

Structure provides great flexibility, so you could have a different hierarchy model in different projects if you wanted. It wouldn't be the same as having a "hierarchy scheme", in that it wouldn't prevent someone from adding a contains <-> belongs to link between two arbitrary issues, but it certainly is possible to implement a deeper hierarchy without Premium.

Like # people like this

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events