You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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
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.
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:
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,
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.