How do you think of the new category of Developer escalations in JSM?

[YY哥]

I tried this new category today. It's a new request type and linked to the original customer ticket (e.g. incidents) as shown in the screenshot.

However, developers cannot edit the fields or be assigned to it. In JSM, only licensed users/agents can be assinged and edit ticket information/fields. 

It seems the value of this functionality is limited. What do you think of it? Welcome to discuss it. Thanks.

[Jack Brickey]

Hi @YY哥 , 

correct - only licensed users (agents) can be assigned to issues in a JSM project. Typically you would create a linked issue to a JSM issue in a JSW issue if a developer support is required. 

I need to evaluate the "developer escalation" in the sidebar. From what I read here, this link simply gives easy access to the GSM issues that require developer support. However, I have not used it, so I may be incorrect here.

[YY哥]

Hi @Jack Brickey 

"Typically you would create a linked issue to a JSM issue in a JSW issue if a developer support is required. "

--- Yes. I agree with you on it.

However, I think it's a better way for developers to collaborate with agents through JSM tickets' internal comments (in a single source of truth - the single incident ticket from customer). Only when it's been triaged and confirmed to require code fixes, a JSM bug issue should be created linked to JSM incidents.

Thanks,

Craig

[Jack Brickey]

Developers can make internal comments in JSM issues without a JSM license. They just need to have proper permissions. viewing-developer-escalations 

[Dirk Lachowski]

@Jack Brickey The devs can comment - but how do they know they should comment? They’re not part of the project, so they never see those issues. Is there some documentation about what the suggested workflow is?

[Jack Brickey]

If the developer has browse permissions and comment permission and is added as a watcher the they will see updates. The agent can mention the developer who can respond via comment. This article might help - manage-your-developer-escalations 

[Dirk Lachowski]

Already saw that article (more a list of other article). Problem here: The entry under "What are developer escalations" that maybe is there to explain the general idea just links back to the same overview page - so there's maybe some more info, but not accessible / linked?

That said: The general idea is for a support agent to pick a dev to work on this? There is no queue where devs can just see what's pending and select who's working on what? A support agent has to decide who's the best dev to answer questions for a given issue? That sounds a bit strange. 

How are you guys at Atlassian using this feature? Electing a designated dev contact?

[Jack Brickey]

@Dirk Lachowski , to be clear, I am a user of Atlassian products like yourself. So my input is based on my own experiences. With that said...

I have not used this feature as yet. What I continue to do is simply creat a linked issue in the appropriate JSW project. I will see if I can get further insight and find someone to correct the dock link.

[Gabriel Raubenheimer]

Hi @YY哥 @Jac @Dirk Lachowski ,

I'm one of the product managers here, in Jira Service Management. 

Firstly, thanks for starting this discussion! We're looking to make it easier for agents and developers to work together, including improving this feature, and your feedback is very helpful. And thank you for picking up the broken support link - we are implementing a fix.

Secondly, let me provide some more detail on how we have seen people using this feature. You are correct, collaborators can not be assigned to, nor transition, requests in Jira Service Management.

Developer escalations allow agents to notify developers when customer requests requires development work, and provides a single place for developers and agents to collaborate on that work. They allow agents to provide all the context needed for a developer to resolve a bug or other problem. Multiple customer requests related to a bug or other problem can be linked to a single developer escalation, to create clarity for developers and agents.

As you pointed out, all developer escalations show up in the Developer escalations section in Jira Service Management, and, unlike queues, can be viewed by collaborators. This provides a place for developers to see any potential escalations that require their attention.

To notify a developer, customers often use automations that send a message to the development team's Slack of Teams channel. These automations are commonly based on the Services or Components field in a developer escalation, but any field can be used. However, we are also looking at better methods of doing this, particularly notifying developers from within Jira.

Developers then create linked issues in their Jira project, and can provide updates to agents via comments on the developer escalation, including when they are complete. Comments can be synced to child issue if desired, via automations.

Developer escalations are important to us, and I very much value your feedback. I have a question for you - in an ideal world, how would this work? If it is better for you than typing, I'd love to hop on a call and discuss your use case and how we can improve this feature to better enable you and your teams. Let me know.

Cheers, and thanks again for the feedback!

[Dirk Lachowski]

@Gabriel Raubenheimer Many thanks for the update and especially for suggesting an automation to ping devs. Totally makes sense and i hadn't thought about that option.

In an ideal world, the solution most likely depends on how the dev team(s) work. I don't think there's some one size fits all way of doing it. For us, an escalation means something is badly broken - this stops all other work, so id'd like to see the escalations in my current sprint's board. For others it's maybe not that black and white and they will add priorities and only have certain escalations bugging them.

That said, escalations should be a rare event, so just having some notification in a well known spot should do it in most cases. 

[YY哥]

Hi @Gabriel Raubenheimer 

Thanks a lot for your detailed reply.

Different user scenarios/cases need different solutions. I'd like to share my practice if you need a zoom call. Hopefully, there's a Chinese colleague with us talking 'cuz my English is not good ☺

Regards,

YY哥