nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Yong Yang

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.

Accepted answers

All comments

Jack Brickey

Hi @Yong Yang ,

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.

Yong Yang

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_b0vz9b

@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_b0vz9b

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 @Yong Yang @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_b0vz9b

@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.

Yong Yang

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哥

Csaba Vertessy_voxr2o

Hi @Gabriel Raubenheimer ,

What do I miss here? For some reason it doesn't makes sense for me.

Why should I create a Development Escalation (as far as I understood) in the same Service Management project if by adding a developer as Collaborator to the Incident, I will be able able to interact with him (using Internal comment)?

Secondly, let's say, I create the Development Escalation; then I would need also to copy/paste the information from the Incident itself. And then, the dev will create a corresponding Bug ticket?

And I don't like the suggestion "to get this and that to work, use Automation".

Please correct me if I'm wrong.

Rocco De Angelis_dx0oec

Hi @Gabriel Raubenheimer ,

Are there any planned improvements for the "Development Escalation" feature?

Currently, we find it challenging to understand how this feature is intended to be used. It is unclear how developers should be made aware of open escalations. It seems inefficient for all developers to check the list of current escalations to see if there is something they need to address. Additionally, having the support agent mention a specific developer in the escalation is not a practical solution, especially with hundreds of developers to consider.

Furthermore, since Jira Software is the primary tool for task management for developers, we would expect escalations to appear as tasks in Jira Software. The only benefit of that feature seems to be the "Escalate" button in the UI and the automatic correct linking. We have now created an automation that will create a Jira Software issue when a request type of "Developer Escalation" is created. Is this the best solution?

We are also open to discussing this further in a call.

Yong Yang

Hi Rocco,

I think Incidents feature in JSW projects is more useful. We can add the service-related JSM incidents to JSW projects so that delivery team can see them directly in the project they're working at.

Regards,

YY哥

CHIQUET Alexandre

Hi @Yong Yang ,

Do you know when this features will be available ? It still show "In Deployment" status in my organization, since December.

Yong Yang

Hi @CHIQUET Alexandre

It should be available to you. You could check it through:

Hope it helps,

Thanks,

YY哥

CHIQUET Alexandre

Hi,

I was actually talking about the incident feature, it is showing like this in my organization settings :

Risto Pearce_9hlkec

hey @Gabriel Raubenheimer

Thought I'd drop my 2 cents in here.

To be fair, the feature in its current form is not very useful as software teams are not effectively in control of their tasks because:

there are no indicators for them to understand what stage of processing the request they are up to (when have I done my work? Did I work on that? etc)
No way to determine or assign someone in the team to work on it.
This feature does more to increase confusion than resolve it.

Also I'm not a fan of just "pinging" devs in slack. ITs not a manageable process where you can ensure a response. Ticketing systems are designed to eliminate the "Toss it over the fence, my job is done" mentality by ensuring accountability.

In this type of feature I'd expect:

An escalation request can be assigned to a team, and the team decides who is scheduled to review and triage incoming requests.
The escalation ticket should be assignable by the team members themselves.
The escalation ticket should allow for developer status changes, so they can track if there are further actions they need to take.
Escalation tickets can be seen in their day to day boards.

My suggestions is that the escalation just get the following:

"Escalated To Team" and Escalated Assignee" fields, that can be changed by collaborators.
collaborators can change ticket status, and make internal comments only
Tickets can be seen in Jira Software boards.

Maybe this could be an extended feature set provided as part of the Jira Premium subscription? Because really, Jira premium should build on collaboration across the organisation....

Happy to jump on a call for for further details.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-service-desk-cloud

escalation

jira-service-management-cloud

jira-service-management