Dear all,
I would like to inform you that this issue in the project JPOSERVER is being migrated to the new project JSWSERVER. Your votes and comments will remain unchanged.
Our team at Atlassian will continue to monitor this issue for further updates, so please feel free to share your thoughts or feedback in the comments.
Sincerely,
Aakrity Tibrewal
Jira DC

I agree with the above comments in that ultimately, in addition to the current generalized linking functionality we need customizable but explicit "parent link" and "child link" concepts so that we can define our own work breakdown structure. Having two issue layers (plus the unicorn type "Epic") is constricting and forces us to modify process to fit around the tool, which is very frustrating.

This whole part of the tool needs to be rewritten.

Database linkage should be "Parent Link" (Parent Key is probably a better name) that defines the whole tree structure –

Custom Type -> Epic
Epic -> Story
Story -> Subtask
Custom Type -> Custom Type

Now there are tree traversal complexities and loops that could pose issues, but this can be offset with issuetype "levels" that can be set in the settings; this guarantees a tree like behavior with no loop backs.

–

Hi rfine. The issue here is absolutely relevant. JIRA has too many ways of linking issues, which makes traversing hierarchies tough, both using the REST API, but also JQL in the UI. Adding Structure and ScriptRunner it becomes evident 3rd party plugins are struggling as well.
There may be reasons for the variety, like company acquisitions in the past.
Two things I've come across which is making the tool hard to use in a divisioned corporate environment:

• Hierarchy in Portfolio is a global thing. R&D may have one hierarchy, but Production and Sales have different needs for instance. We cannot offer high level planning for these parts without imposing alien names, like Epic and Story.
  • Suggestion: Allow hierarchy schemes, like we can design workflows in JIRA
• Portfolio only uses time fields or "Story Point" fields for calculation. In our environment we have high level Portfolio Epics which gather sizing from 5 different departments (HW, Mechanical, PC SW, embedded, SW etc.). Each of these departments give their size in a custom field. The sum of these is the total size of the Portfolio Epic, only there is no great way to make Portfolio understand this is the case.
  • Suggestion: Allow in some way to select a group of custom "User Story" fields to make up the basis for calculations in Portfolio. It could be just "Story Points" or in our case SUM("Dept1 SP", "Dept2 SP", ...).
  • This must be configurable per hierarchy level as it is likely only the top aggregated levels have multiple SP sources.

Hi all, 

I am a product manager at the Portfolio for Jira team. We are looking to improve the integration between Portfolio and Jira. Namely, we are looking for ways to help you plan and track work with the help of Portfolio concepts such as the team field, issue hierarchy, etc. 

I would love to hear about some planning and tracking use-cases you have where Portfolio can do better job to help you with.

Please leave a comment here, alternatively, you can schedule a 30 min call with me in this link: https://calendly.com/rfine/30min

Roi Fine | Product Manager

I agree, e.g. a simple Jira Pie Chart could nicely use the "Parent Link" as Statistic Type ... but it is not available 

We would love to see, which Sagas/Initiatives have how many issues.

"Epic Link" is available:

Hey rchristian@atlassian.com,

I've been a detractor in the past due to this deficiency, and I'm sorry to say this doesn't help me at all. I don't need MORE jql functions. I don't walk linked issues with JQL, I use issuelinks. I need Portfolio to play ball with the way everyone else in the ecosystem is doing linked issues instead of re-inventing the wheel.

Without properly linked issues or at least a public JAVA api, this is still something I cannot develop alongside and Portfolio simply lives in it's own black box, where I am unable to actually integrate with.

Please reconsider spending time solving this at a high level and rework the system to play ball with Jira Software, ScriptRunner, and Structure.

+1 for Cloud.  Cloud is the future, guys.  Get with it.

This along with other Portfolio limitations is causing us to re-think the fairly high cost of Portfolio.

Thanks!

Hi there, which is the roadmap for cloud instances?

kind regards

Thanks Rhys

  I'll give it a spin.  One thing about using a new link field is that those that have hierarchies setup using the 'normal' linked issue functionality still have to maintain double work.

 I must comment as well that it is counterintuitive as well to have multiple ways to link issues.  From a user point of view it is excessive and unneeded to introduce more JQL syntax to mine data from a database with special cases here and there.

 I'd like all links between issues to become the "linked issues" kind, parent/child links from Portfolio, parent/child from linked issues, and Epic link are to me all the same kind - maybe not in name of type-wise.

Regrads,

Kim