Jira Software and Jira Service Management collab

[Sierra]

I'm interested in how other companies are using Jira Software and Jira Service Management independently from each other or in collaboration ? 

As a company we heavily use Jira Service Management project. Attempting to crack into the Jira software product , although , our developers still work in Rally for now. 

I have a set of developers that like the Kanban board .. they are filtering issues in from the Jira Service Management project and not working within the queue in the Service Management project. Does anyone have any thoughts or opinions on this ? 

[Marlene Kegel - codefortynine]

Hi @Sierra,

I am Marlene from codefortynine.

In 2019 I interviewed one of our Deep Clone customers about collaborating between JSM and Jira Software projects. You can read the article about his use case here: https://community.atlassian.com/t5/Jira-Service-Management-articles/Escalate-tickets-in-Jira-Service-Desk-with-Deep-Clone-for-Jira/ba-p/1244255

Note that Deep Clone for Jira is more powerful today than it was back then - but the described use case is still possible, and even more :) 

[Florian PEREZ [Valiantys Administrator]]

Hey!  

We've just discuss this point with community leader this week and it's remarkably interesting ! There are so many ways to do this and let's be honest it depends mostly on the needs.  

Would love to get more information on this but let's go with what I'm used to do.

When working on JSM, the team should ALWAYS use queue. This is a particularly good practice plus the smartest way to get all team in the same place and avoid confusion on who's doing what. It also allow to see redondant ticket to be able to identify a potentiel bigger problem more accurately.

Agents must stay on queue.

If needed (and it is often the case) you can involve Jira user (no JSM licence) on tickets. There's many way to do this but I'm using two ways : 

First case, we just need an advice (from a tech lead for example). For this case we keep all simple. Agent just @ in comment the user they want the feedback / opinion, and they move the ticket on an on hold internal status. This status is clearly identified in a queue so agents can send a new message if @User not responding. Sometimes I also create SLA on this part just to show agent more easily when they need to act again (eg. the @User not responding)

Second case, we need a specific development, or we need the buyers of the company to do actions. In this case we clone the ticket (or we create a linked issue) in the corresponding project, letting them do the action. To be sure it's done on time we fill a due date on the clone ticket so teams know what's expected in terms of timing. When the cloned/linked ticket is resolve on side project the status is updated on JSM project, agents get a notification, and they can finish the action. 

Hope this help : )