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
I have configured Jira Portfolio with the typically recommended hierarchy:
I want to modify the hierarchy to be:
What impact will that have on any existing plans?
How can I identify existing plans/owners that may be impacted by the change?
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.
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.
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.