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

Portfolio hierarchy change impact?

I have configured Jira Portfolio with the typically recommended hierarchy:

  • Initiative
    • Epic
      • Story
        • Sub-task

I want to modify the hierarchy to be:

  • Initiative
    • Feature 
      • Epic
        • Story
          • Sub-task

What impact will that have on any existing plans?

How can I identify existing plans/owners that may be impacted by the change?

3 answers

1 accepted

0 votes
Answer accepted

This is a tough question to answer.  JIRA comes with a defult Issue Type called Feature.  Is that the Feature you are trying to use?  

If so, then it will not work in Portfolio.  Portfolio is limited, you could use Components as your Feature and that would work.  

Our JIRA instance does not currently have a "Feature" issue type (only "New Feature").  So the referenced "Feature" would be a new issue type.  The basis for my question is that I am integrating Aha! to provide high level requirements information from product management.  For this reason, components don't fit into the necessary object relationship. By inserting Feature into the Portfolio hierarchy as the means of aggregating Epics (defined as feature sub-sets by development) and linking requirements to features and stories, I can then use Portfolio to close the loop to verify scope and schedule delivered by development with scope identified through requirements requested by product management. Aha-Jira.png

We got the addon from cPrime to change Epic to Feature.

 SAFe Fun.jpg

Thank you for the feedback, John.

This is interesting, but I don't want to change Epic as that would be traumatic to our dev community and we have a need for both Epic and Feature. 

I think I have my answer in that changing the hierarchy does, in fact, break any existing Portfolio Plans that have aggregated Epics by Initiative.  Fortunately, the number of impacted plans is low and the users were accepting of the change.

It would be nice if Portfolio allowed hierarchies to be specifically defined by project to override a default.

Like Julie Taubman likes this
0 votes
Rhys Diab _Agile Docs_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
May 29, 2019 • edited

Hi Ross, I recommend sticking with the default issue types for next-gen projects (epics, stories, tasks, bugs) to make it easier on your team.

Portfolio has alot of features and is generally pretty good, but I find it brings lots of complexity.

That's why I put together Agile Docs, an interactive hierarchical view of all the epics, stories and tasks in your project with zero configuration. It looks like this:


As an added bonus, you can create, edit and delete projects, epics, stories and tasks directly from the interface like editing a google doc. All the parent child relationships are created and removed automatically for you.

I'm obviously biased towards my own app, but if you're looking for something simpler than Portfolio I recommend giving it a try.

I really appreciate you passion for your product, but ...  

I have worked with it for years and I know you and Atlassian can a world class product.

I really mean this, please let me know how I can help!

We have modified our issue hierarchy in Portfolio.  It doesn't break anything (that I can tell), but I would caution.  It has caused a lot of confusion and people are forced to add a layer when one isn't really needed.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events