TFS4JIRA Azure DevOps integration: Can not link stories to features in JIRA, that exist in ADO.

[mari_guernsey]

Hello

I am still working on a proof of concept with the above app, This is to ensure that mutlple teams working in ADO do not have to migrate to Jira, Reporting is being done by Leadership in Jira, so we need to basically have what we have in ADO, be reflected in JIRA, to generate that reporting

In ADO we have Epics, Features, Stories, Tasks. I have configured these also in my test environment (Jira)

I thought it was all going good until I manually tried to link a story to a feature before I initiated the sync

I'm told Jira doesnt work that way OR if it was changed it might mess up everyone else using Jira, as it may not be a project based config setting

Basically we dont know how to proceed

Please can anyone help me out here. This is a pretty important POC for us

[Trudy Claspill · Accepted solution]

Hello @mari_guernsey 

Jira's default issue hierarchy is

Epic
|-- "standard" issue types - Story, Bug, Task, etc.
    |-- sub-task issue types

The issues at the "standard" level are the items that would be planned in a sprint.

Issues at the sub-task level only exist as children of issues at the "standard" level. Sub-task are not planned independently in sprints but are carried along with their parent issue.

Note that the Jira hierarchy doesn't support issues at the same level being "children" of each other, so a Jira Task could not be a child of a Jira Story.

Epics are a unique issue type in Jira with some unique functionality associated to them that works only specifically with the issue type named "Epic".

With the Premium subscription it is possible to extend the hierarchy upwards above Epics, adding more levels. This is a global configuration that is set for the entire Jira application. It is not possible to have separate hierarchies per project.

Those additional hierarchy levels can be visualized hierarchically only in the Advanced Roadmaps features. The additional levels cannot be visualized hierarchically within Jira agile boards.

While it is possible to change the display name of the Epic issue to "Feature" and then add a new issue type named "Epic" and place that above the "Feature" in the hierarchy, that does affect the entire Jira application. Everybody's use of the original "Epic" issue would show "Feature" instead. Renaming the Epic can also have impact on other aspects of functionality. I recently learned that third party apps that add special JQL functions that relate to search criteria for Epics can break when the name of the original Epic issue type is changed.

There may be a way to achieve what you want, but I can't think of a way to do that. I have not tried to do it, and don't have a suggestion for how you can get Jira to exactly mirror the hierarchy you have in ADO.

[mari_guernsey]

@Trudy ClaspillClaspill

Thank you very much for your detailed response. You really did work through the question logically for me. In our company, they have configured an "Initative" and that child is an Epic and a child of that is a Story.

In ADO, we have EPIC and the child of that is a feature and the child of that is a story,

I'm unsure if "initiative" is out of the box with Jira, but its working as a parent.  I'm not following this.

"While it is possible to change the display name of the Epic issue to "Feature" and then add a new issue type named "Epic" and place that above the "Feature" in the hierarchy, that does affect the entire Jira application. Everybody's use of the original "Epic" issue would show "Feature" instead"

If Epic issues is currently the top, when you rename it to Feature how can you put an issue type over it, I thought the EPIC/Feature was the parent?

[Trudy Claspill]

For simplicity I'm going to refer the the terminology that matches my example screen images, where the "Epic" level issue is still called "Epic" and the level above it is called "Feature"

The Issue Hierarchy configuration is managed by Jira Administrators. The screen looks like this:

This is the hierarchy that can be visualized in an Advanced Roadmap Plan.

In this example notice in the Jira Issue Types column that the Epic and Feature levels each have two icons. That means there are two types of issues that can be used at each of those levels.

So to add a level above the Epic level you need to first have an issue type created that you can place there.

Then you update the above configuration to add the level and add the issue type to it.

To then use that new issue type/level, the issue type at that level has to be available in your project.

Then you can create an issue of that type.

There are a couple of ways to connect an issue from the next level down.

You can use an Advanced Roadmaps Plan that encompasses the issues to drag the epic from its current position and drop it under a Feature.

If the Jira Administrators have exposed the Parent field in the Epic issue type for your project, then you can edit that field directly in the Epic and enter the issue key for an existing Feature.

[mari_guernsey]

Thank you @Trudy Claspill I will mull this over and share with our Jira Administrator to see if we can do something similar without messing things up for everyone using Jira

We do not want to add a level above Epic, for our needs we want to add a level under Epic.. We already have the initiative Level above Epic.

I'm appreciative that you showed me that screen shot cos that opens up the conversation on my end. I don't normally see this backend config functionality.

Mari G

[Trudy Claspill]

Jira does not natively support adding something between level 1 (where the native Epic is) and the level 0 (where the "standard" issue types are), that Jira would then recognize as a parent/child relationship.

You could artificially use generic issue linking to indicate one standard issue type (i.e. Task) is a "child of" a sibling standard issue type (i.e. "Story"), but Jira would not see that as a parent/child relationship and would not provide any native parent/child functionality for that relationship. 

[Adriana Hernández (Appfire)]

Hi Mari, 

I'm Adriana from the Appfire Support team!

Thank you for your interest in our TFS4JIRA app.

Regarding your questions, to add more information to this case, Jira only has three levels by default: Epic > Standard Issue type (Bug, Task, Story, Custom standard issuetype, etc.) > Subtasks (Subtask, Custom subtasks). In Azure DevOps, we can find multi-level hierarchies; for example, in Azure DevOps, a Task can be a parent of an Epic, and this Epic can have another Epic as its Child.

With the TFS4JIRA app, we can replicate Azure DevOps multi-level hierarchies in Jira through a Jira custom link type, 

You can create this custom link in Jira by going to Settings > Issues > Issue Linking > Add. 

Then, add this configuration in TFS4JIRA by going to your Profile> Mappings > Hierarchy > Multi-level-hierarchy synchronization > Select the Jira custom link created before.

After this, if everything else is already configured (types, statuses, fields, etc.) and the Profile is enabled, you can start synchronizing from AzureDevOps to Jira to test this configuration.

Here is an example of my configuration:

In the screenshot above (SS-3), the issue DTCN-192, a custom standard issuetype (Feature), is the parent of the Epic DTCN-194.

Here is another example:

In the screenshot above (SS-4), one of the Stories from the Epic DTCN-194 has two 'Child' Tasks (standard issuetypes) DTCN-196 and DTCN-197.

Lastly, here is another example:

In the screenshot above (SS-5), Subtask Synchronization is also enabled in TFS4JIRA. This allows us to have another layer after the Tasks in the example before (SS-4).

Please note that for this TFS4JIRA configuration, I used the default Issue type hierarchy configuration in Jira.

Please let me know if you have further questions or concerns. We'll be happy to assist you.

Best Regards 

Adriana 

[mari_guernsey]

Hello Adriana

Thank you for all the screen shots and step by step instructions. Are you suggesting we call our Features (EPICS) and our EPICS (Features) and have a parent child relationship that way? Since in Jira is seems like features will always be the parent of a child. 

It that the only way you have seen other companies successfully sycn the data? I've never liked this aspect of Jira as in the 'real world' an Epic is always the parent of a feature in Product Mgmt, regardless of a tool, even if we were using big stickies on the wall!

[Adriana Hernández (Appfire)]

Hi Mari, 

Thanks for the reply,

My screenshots in my last comment were just a use case example, using Epic issuetypes, Feature (a custom standard issue type), etc. 

In TFS4JIRA, you can map types according to your needs, for example:

But, recall that Epics are a unique issuetype in Jira. When using the Jira Epics native configuration (Epic Link), their child issues can only be standard issue types, and the representation differs from other Jira relations. 

In TFS4JIRA, you can map any Azure DevOps workitem type with the Jira Epic issuetype, and you can choose to use the native Epic Link field, which looks like this:

Or use the Jira custom link type we created before:

Please share more details of your use case to provide a specific solution, 

For example, you can share how your hierarchy is used in Azure DevOps and how you would like to see it in Jira.

Here is another use case related to hierarchy:

Please feel free to check more details about the Jira/ADO integration in this article:

https://hub.appfire.com/software-development-and-devops/integrate-jira-cloud-and-azure-devops-with-tfs4jira/

Also, here is our official documentation where you will find information to configure your TFS4JIRA profile step-by-step:

https://appfire.atlassian.net/wiki/spaces/TFS4JIRA/pages/148178069/Configuring+issues+and+work+items+synchronization+-+Cloud+Native

Please let me know if you have further questions or concerns. We'll be happy to help you with your POC.

Here is the link to our support portal in case you would like to submit a support request to us: https://appfire.atlassian.net/servicedesk/customer/portal/11

Best Regards,

Adriana 

[mari_guernsey]

Hi again Adriana. This pic was helpful. We have figured out the configuration steps but we need the features in ADO which are linked to the Epics in ADO, to ALSO show this parent child relationship (Epic -> Feature) and then also the Features be the parents to Stories as the end result.

How do we achieve this. Its my understanding from another responder that in Jira Features and Stories being both Issue types, one can not be the parent of the other, like they can in ADO

What have other ADO customers done? Do recall?

[Adriana Hernández (Appfire)]

Hi Mari, 

Thank you for the additional details, 

I did a test on my end. You can see the results in the following link:

video_demo_hierarchy

Let me know if you are available to see the screen recording, and also, please confirm if the hierarchy in the screen recording corresponds with your use case. 

Here are the screenshots of this test:

1. TFS4JIRA configuration used

2. Creating Azure DevOps workitems and linking them: Epic, Feature, and User Story.

2. Jira Issues created by TFS4JIRA with the TFS4JIRA - EPICS synchronization configuration disabled.

3. Jira Issues created by TFS4JIRA with the TFS4JIRA - EPICS synchronization configuration ENABLED. 

Check the screen recording below for more details related to point 3.

video_demo_hierarchy_2

This is how our customers have achieved representing the Azure DevOps multi-level hierarchy in Jira. 

Please note that the custom Jira link type 'Parent-Child' that TFS4JIRA uses to represent this hierarchy is not part of the Jira built-in configurations to represent issue hierarchies at all, this means that this Jira link-hierarchy won't be visible in roadmaps or timelines. (I showed an example of the timeline view here: video_demo_hierarchy_2 .)

Also, as you can see from the previous screenshots, we can only see the parent and child links of the current Jira issue; we can't display more layers than that because this is how Jira works.

Please let us know if you have more questions or need further assistance, 

We'll be happy to help you!

Best Regards

Adriana

[mari_guernsey]

HI @Adriana Hernández (Appfire) , would you be available for a call? Due to our firewall I'm not able to view any videos you put into the dropbox,

I would love to see what the Board Looks like and the Backlog. if you can provide screen shots?

Thank you

Mari

[Adriana Hernández (Appfire)]

Hi Mari, 

Thank you for the meetings, 

As discussed, issues will appear on the board if they match the board configuration, and the board features will also depend on the type of project used. (Company-managed or Team-managed)

Please let me know if you have further questions or concerns about TFS4JIRA,

we'll be happy to assist you.

Best Regards

Adriana

[jennifer.dempsey_Appfire]

Hi Mari,

I chatted with you a few weeks back regarding TFS4JIRA. Have you had a chance to contact our support team with your question? If not, I'd be happy to put you in touch with someone who can help.

[mari_guernsey]

hi @jennifer.dempsey_Appfire  I was not unfortunately as this seems to be more of a Jira thing than an app thing. I tried to manually create things, before i did a sync and it showing up the way I hoped it would.

Unless you think they have suggestions, maybe they have seen this ask before?

Mari G

[jennifer.dempsey_Appfire]

Hi Mari,

I'm checking with them now and will update you as soon as I have an answer. 

[jennifer.dempsey_Appfire]

Hi Mari,

It looks like you're getting some good responses from the community! If you still need help, please feel free to submit a support ticket or send me an email and someone from our team will be happy to assist you further.