Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

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

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

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!

Leaderboard

Hierarchy Configuration - need to assign issues types to more than one level

When creating levels above the default, the drop down that lets me choose the issues types to assign to the level excludes any that I have explicitly assigned to another level. We have a need to assign a couple of issue types to more than one level... how can I configure Portfolio / Jira to permit this?

1 answer

1 accepted

0 votes
Answer accepted
Stephen Wright _Elabor8_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Oct 04, 2019 • edited

Hi @Mark Mayotte

I don't believe this is possible. The hierarchy is set to allow for Portfolio to function with a breakdown of work from top-to-bottom level. Having issue types at multiple levels would make it difficult.

You'd need to consider a much more flexible option to achieve what you're looking for - such as using Linked Issues - and then using an app like Extended Schemes for Jira to control which issue types are available to which link type.

It's not something I would personally advise though as the hierarchies help with reporting, visualisation on boards / Portfolio, etc. What's the specific use case you're looking to apply to this? Happy to help you consider an alternative :)

Ste

We have some teams that work in Full SAFe, and others that work in Portfolio SAFe. That means within the Jira instance, which includes the Portfolio for Jira tool, we have a need to support both models. Each group would always follow a top-to-bottom breakdown... just some groups would exclude a level. 

Using linked issues we can, and do, set up arbitrary dependency trees... it is just not conducive to visualization as you call out.

Stephen Wright _Elabor8_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Oct 11, 2019

Which level is it that teams exclude? If you can provide your hierarchy that'd be ideal.

Ste

hierarchy.JPGThe orange icons are Portfolio-Epic & Enabler-Epic, the blue are Capability & Enabler-Capability. The purple icons are Feature and Enabler-Feature. The need is to also place the orange issue types at the Large Solution level of the hierarchy. This would permit organizations that do not use/need a four-level hierarchy to "skip" the use of Capabilities... and link Portfolio-Epics to Features (as is done in Portfolio SAFe). We'd ensure things are not confusing by the way we assign issue types into projects that are actually pulled into a plan... if the large solution level was not needed then there would be no project created that used them... and therefore the Portfolio Plan would be constructed without them. 

The only workaround I can think of is to create cloned issue types at the Portfolio level and duplicate everything in the workflows, screens, etc. Again we'd eliminate confusion by how we construct the projects that consume the issues... 

Like Christopher Chan likes this
Stephen Wright _Elabor8_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Oct 19, 2019

Apologies it took sometime to respond - but I think your solution makes the most sense!

From a user perspective it'll seem flawless as you can control which issue types they can use at the project level.

Just remember you don't need to duplicate the workflows or screens - you can utilise the same ones by adding them to your screen / workflow schemes.

Ste

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events