A fresh look at SLAs in Jira Service Management

[#1]

Update

We have just deployed an update to this feature that lets project admins choose which display format is best for each SLA in this project. Learn more below.

Starting in December we are rolling out a notable change to the way SLA expiry is displayed in Jira Service Management.

SLAs: Old format vs New format

The new format presents the time until expiry as a due date, as opposed to a countdown timer of the hours and minutes until expiry. The hover state in the new format displays the original behaviour.

The new hover state will show a relative date for Yesterday, Today, and Tomorrow, and for all other times, it will show the date. Learn more.

Choosing the right format for you

Based on your feedback we know that different formats work for different SLAs/projects. When creating/editing a SLA, select the display format that works for that SLA. You can change the format whenever you like, but keep in mind each time an SLA is saved issue goals will be recalculated.

Why we think you’ll like the new format?

Computers work in numbers, no matter how many hours and minutes are remaining, they immediately know how to translate it into a due date. For humans on the other hand (no matter how good you are at maths) it is not as easy.

Removing ambiguity

Let’s look at some examples:

If there are 2 hours remaining that is easy… right? But what if it's the end of the day? Then actually it won't expire until sometime tomorrow morning. What if the calendar excludes tomorrow, then it might not expire until next week.

For SLAs longer than 24 hours, this gets even more complicated. If there are 37 hours remaining, when will the SLA actually expire? Which calendar is it using?!? 😵‍💫

As you can see, there is no easy way to know exactly when an SLA will expire, we want to help you avoid the algebra and get back to delivering value to your customers.

Feedback

We would love to hear what you think about this feature. Please leave a comment and if you are ok with us getting in touch for a discussion.

[Dirk Ronsmans]

Normally I'm not a fan of those "yesterday"  type of date notations and having to hover, but this one actually makes sense!

I never really considered the fact that you couldn't see the calendar as a bottleneck but I totally get that.. 

Looks good!

[Deleted user]

@Benjamin Paton  Very interesting, thank you for informing us. I want to ask you, but have you solved the problem that if you create a SLA, it is not possible to rename it, unless you delete the whole thing and do it all over again?

[Benjamin Paton]

@[deleted] thanks for your feedback. Renaming SLA not fixed yet, but is definitely on the backlog.

[Tanya Christensen]

This is great news.  I sort of wish I was back on my last companies' service team to see this in action and pass along to customers.  

[Jerry Siskind]

I prefer the old method. Please provide the ability to choose the old way as it is more applicable to our needs. Having to hover over every entry is not an improvement for me.

[Steph Bannister]

How are the times now exported when I do reporting to show how long before or after the SLA goal the reply was sent?

What would be best for reporting is the actual time in hours/minutes that it took to send the reply (a count-up timer only). Is this feature planned anywhere?

[Péter Péli]

How to revert old time format? For us it is so very uncomfortable now. 
It causes a lot of extra work :( 

[Dirk Ronsmans]

@Péter Péli can you elaborate how exactly this causes extra work?

[Nikolay Petrov]

Hello,

I can actually explain why this is bothering us.

Our bigger teams usually prioritize tasks based on the remaining time.

You make the assumption that it is easier for the computer to calculate the due time thus better for the user but you tell me what is easier to read - Today 10:36 or 34m. 

You also conclude that the new format is better for the end-user (customer) but the changes ignore teams that communicate with customers in languages that don't support translation in Jira plus teams that communicate with the customers mostly through e-mail (we don't oblige our customer to enter the ticket. they reply through e-mail).

I am unsure how this improvement was reviewed but I suggest giving us a menu where we can choose how it is displayed - for us and for the customers.

Best wishes,
Nikolay Petrov

[Hubert Bedyk]

Hello,

it end of the month, definitely more than "2 weeks" and on my Jira Cloud Service Management Project o still see "-7,617h 18m". Should i do something more or change any setting?

Second, do you have plans for making as a setting - old one or new one to choose for?

Happy New Year!

HB

[Péter Péli]

@Dirk Ronsmans We're operating a public bike sharing system.
JIRA performs KPI and SLA calculations.
We’ve created a module in it to help redistribute bikes.
If a bicycle is not available at a station for a certain period of time, the monitoring system will open a ticket in JIRA. There are several types of grace periods, which vary from station to station.
The queue in the image shows that SLA violating notifications are sorted in descending order of time remaining. Due to the specifics of our city, a dispatcher directs logistics colleagues from where to where they should move the bikes, thus resolving the SLA violation.
Hundreds of these tickets can open and close daily without intervention. We work 0-24 every day.
Now, since the update, the dispatcher has to hover the mouse over the stations one by one to see how much time is left and make a decision accordingly. This causes difficulty and extra work and degrades the user experience. All of our users have complained since the introduction and we don’t know what answer to give them what to expect.

[Benjamin Paton]

Hello all, 

Thank you for your feedback over the holiday period. I am back in the office as of today, let me provide some responses. 

@Jerry Siskind @Péter Péli @Hubert Bedyk we currently do not have plans to make it a setting, but we are evaluating feedback. If it were a setting, from your perspective how would you configure it? (e.g. per site, project, or SLA).

@Steph Bannister reporting remains the same. Behind the scenes an SLA is still a countdown of hours and minutes. We have no plans to change it to be a round-up, but this is something that can be calculated for reporting purposes.

@Hubert Bedyk if you still have not seen the change it will arrive for you this week, the final phase of the rollout is scheduled for 6 January.

@Péter Péli @Nikolay Petrov thank you for taking the time to provide extended feedback.

Cheers, 

Ben.

[Steph Bannister]

@Benjamin Paton Thanks for this reassurance!

Steph

[Hubert Bedyk]

@Benjamin Paton IMO the best way is settings per site as default for all projects and setting in every project if you need other way in a particular project. And as simple as it can be - for example one option with two values: old format - new format.

[Péter Péli]

@Benjamin Paton 

Project settings or user profile setting

Anyway, I'm done with a workaround

I created a customfield (for old sla remaining time)  and checked the API response:

I use Automation to read the API response and modify the customfield
example smartvalue: {{fields.customfield_10106.ongoingCycle.remainingTime.friendly}}

I'll show the result in the queue.

Unfortunately not a very cpu time friendly method, but suddenly we couldn’t figure out a better one.

[Chris Hansen]

The purpose of this original ticket request was to give admins the ability to choose the display format that best suited their JSM project, and how their teams wanted to view SLA's. We did not accomplish this here.

Now many users are stuck having to hovering each ticket SLA to see the time remaining. There needs to be an update at the project level immediately that allows users to choose their SLA display format in the Old version. Please give us options and don't force a path that's not natural. - Thanks Chris

[Benjamin Paton]

@Hubert Bedyk thanks for the feedback.

@Péter Péli very impressive workaround.

@Chris Hansen we are always trying balance capability and complexity. Can you tell me more about why the new format does not work for your team?

[Chris Hansen]

Hi @Benjamin Paton - No problem. I know how it can be. I do think adding options in the project settings for SLA's w/ old & new formats would have made us happy.

Here are a few reasons why the new format doesn't work well for me and my team. 

• It requires our teams using JSM to either do math in their head or hover over each ticket to see how much time is remaining.
• When trying to not only met the SLA, but beat it looking at a date when the ticket needs to be completed by doesn't give quick and easy visibility into how long a ticket has been on the service desks teams plate for. Sure you could add the created date column to a queue, but again then you're trying to figure things out. 
• When looking at my team's queues (e.g. avg. response time) to tickets I can't quickly see how long it took them to respond to certain issues w/o hovering over each SLA. Whereas before I could quickly see the state of all tickets and how quickly we responded to our customers.
• We also noticed that the column for SLA is sometimes hidden in our queues making it sometimes hard to read the date timestamp in it's entirety. 

See here: 

[Benjamin Paton]

Thanks for the feedback @Chris Hansen. We are working on an update to increase the minimum column width for the SLAs to ensure they are displayed more effectively.

[sally usherwood]

Good Morning All, 

Can I just check that I am reading this correct, please?

Resolution SLA due (or expired)  04/11/2021  @ 11:56

Actual Resolution time 07/01/2022 @ 2:22pm

Total Breached time : -332h 12M

[Dirk Ronsmans]

@sally usherwood that sounds right to me.

[sally usherwood]

That excellent, Thanks @Dirk Ronsmans  :) 

[Wendell W]

Honestly, this feature seems like a step backwards for me. The countdown timer helps my team prioritise tickets and decide which ones to do first.

It's quicker and more natural to look at a countdown timer than the way it is now.

Please provide an option for your customers to choose which SLA format they want!

[Vladimir Virlan]

Please revert or provide an option to customize.

May I ask why didn't you set the new format in the tooltip as an improvement and leave existing format in the main field as it was?

Before I knew how much time is left exactly on a task. Now it shows me an abstract point in time in a different timezone!

Example:

Before: 1 hr 45 minutes left

After 30 Nov 11:45 AM

Now I have to subtract 11:45 from current time to know whether I have enough time left or not! In addition I have to calculate for the timzeone offset.

This scenario proves your argument (but in reverse of what you meant - this time humans must convert back from due date into time left):

Computers work in numbers, no matter how many hours and minutes are remaining, they immediately know how to translate it into a due date. For humans on the other hand (no matter how good you are at maths) it is not as easy.

Also, it is now very hard to take screenshots. I cannot use the snipping tool as the tooltip disappears when I try to select a screen area.

[Hannes]

Hi @Benjamin Paton

we are Atlassian Solution Partner but experience a lot of unsatisfied customers. The main problem they have:

In the old view they did see the time differene between the SLA Date and the current. This is pretty important for customers. Currently they see only it's breached, but there's no vissible difference between 1hour breached and 100hours breached, only by hover.

This is definitely a big pain we see her for Atlassian customers and disturbs their daily business. There's a strong need to even have the option to  change the format back to the old format (better: to the former Server Format inclund months, weeks and so on, not only hours).

Currently we see even Cloud Migration projects running in a stop because of this. It's a situation we want to impede I guess.

Best Hannes