Can you have an 'issue hierarchy scheme'

[Niall McPherson]

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.  

[Nic Brough -Adaptavist- · Accepted solution]

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.

[Niall McPherson]

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

[Dave Rosenlund _Trundl_ · Accepted solution]

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,

-dave

[Niall McPherson]

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.  

[Kelly Arrey]

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.