Link types used in Advanced Roadmap not compatible with link types used AlmWorks Structure

[Christian Nobs]

Link types used in Advanced Roadmap not compatible with link types used in AlmWorks Structure. 

• Advanced Roadmap uses 'Parent link' and 'Child link'
• AlmWorks Structure uses 'Issue Link' with several types of links (e.g. split, child, cause)

We have heavily invested in Structure and the 'Issue link' are used for our value delivery reporting for 30+ value streams. Now teams staretd to use Advanced Roadmap and they must use 'Parent link' as 'Issue link' are not respected in AR. This breaks our operating model.

Need help:

1. Can we configure AR to respect link types used in Structure 'Issue Link'?
2. If and swer to (1) is no, then is it possible to bulk-migrate from Structure 'Issue Link' to Advanced Roadmap 'Parent link'?
3. any other solution would be welcome

Thanks

Christian

[Mark Segall]

Hi @Christian Nobs - I ran into the same situation of converting from issue links to to parent link and although it's painful upfront, you uncover a lot of bad behavior.  Ironically, while I appreciate what it brings to the table, you don't get enforced "structure" with structure.  The link type is intended for simple mappings like issue A is a clone of issue B or issue X blocks issue Y.  When you try to enforce hierarchies with an unstructured model, you get epics serving as children to sub-tasks of a story... So, parent link will be a more consistent experience going forward.

There's manual activity you cannot avoid:

1. Ideally, you already have the issue types sorted.  If not, you're in for some pain as you'll likely need to "Move" issues from one issue type to another to support the more structured issue type hierarchy required for advanced roadmaps.
2. You need to make sure that all issues have 1 and only 1 parent issue

So, depending upon how much work you have in front of you, you could simply export everything to Excel, prep there with some fancy formulas and perform an import.  For a lighter cleanup effort, you could explore automation...

Note - Depending upon the number of issues, you may have to do this in several batches because of automation limits. Here's how it would work:

For this example, I'll use Theme as my top level and Initiative as my second. Start with THEMES.

• TRIGGER: Scheduled (Frequency doesn't matter, you can execute it as needed)

  • issueType = Theme

• BRANCH: Linked Issues (Is Parent Of)
  • Edit Issue (Advanced)

  • {"fields": {"Parent link": "{{triggerIssue.key}}" } }

Repeat the rule for Initiatives to link up all the Epics.

[Christian Nobs]

Hi @Mark Segall - thanks so much for the insights. We indeed have challenges with Structure to maintain structure consistency and avoid unintenional spaghetti linking.

Will look into your proposed way forward. Thanks again

[Dave Rosenlund _Trundl_]

Hi, @Christian Nobs. And @Mark Segall.  

Agreed. A core Structure design principle is flexibility.  It enables you to adapt Jira to the way your teams work with flexible hierarchies, and more.  So, for example, where Jira and Advance Roadmaps expects you to use a prescriptive hierarchy — Structure does not.  

That also means there's nothing the prevents you from using the Jira/AR hierarchy either. The point is, it's up to you.

That said, this is just one aspect of what Structure adds to Jira.  There's much, much more to the story.

In fact, to that end @Christian Nobs, a member of team has reached out to you on LinkedIn to offer you a discussion with our solution engineering team to discuss your use cases (if you feel that would be helpful).  Our team works with many customers like you that use Structure and AR in concert with one another.

Hope this helps (too -- in addition to @Mark Segall's  helpful answer.

-dave

P.S. Just in case it's not already painfully clear, I am a community leader AND I work  work for the company that makes Structure (ALM Works is now part of Tempo).