Portfolio hierarchy change impact?

[Ross Klippert]

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?

[John Horwath · Accepted solution]

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.  

[Ross Klippert]

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. 

[John Horwath]

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

 

[Ross Klippert]

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.

[Rhys Diab _Agile Docs_]

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.

[John Horwath]

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!  John.E.Horwath@gmail.com

[Karen Hayden]

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.