-
Bug
-
Resolution: Done
-
Low
-
None
-
1.2.1
Issues that are considered resolved are not having their SLAs update accordingly reports in the service. The reports will not accurately represent the actual data. This means that even though a team may have already dealt with 1000+ issues the SLAs and associated reports will only show new information. Especially when dealing with a "Time to Resolution Average" If the goal was originally 240 hours based on a 24/7 calendar, when changed that to a specific calendar (say a 9-5 based calendar) and a 9 hour goal the averages will be thrown way off.
The problems pertain exclusively to historical issues. (ie issues that were marked as resolved before the change to the SLA took place)
For example let's build a mock timeline:
01-01-2014
Create SLA "Time to Resolution"
Goal is 240 hours based on a 24/7 calendar
01-02-2014 -> 02-01-2014
Create and Resolve numerous tickets
02-02-2014
Modify the SLA "Time to Resolution"
-NEW goal is 8 hours based on a custom 9am-5pm calendar
02-03-2014 ->
Create and Resolve numerous tickets
The problem is that the tickets created and resolved during the "01-02-2014 -> 02-01-2014" phase do not have updated SLAs. Those tickets still present to me SLA data from the initial creation of the SLA on 01-01-2014 (goal being 240 hours) instead of updating the SLA to match the new SLA criteria that was established on 02-02-2014. According to the documentation (https://confluence.atlassian.com/display/SERVICEDESK/SLAs):
SLA usage notes
If you edit an existing SLA, JIRA Service Desk will re-index all the existing issues in the project; the re-indexing will ensure that the SLA status on the issues accurately reflects any changed criteria. All the historical SLA data will be recalculated to measure against the new metrics.
As stated previously, all issues should have their SLA data updated to match the current SLA goals and criteria.
In the attached screenshots you can see the following:
SLA Time to Resolution.png
Shows that the SLA "Time to Resolution" is configured for 9 hours, based on the OPI (9am-5pm) calendar and for issue type "ScanIt Support Ticket"
Issue with incorrect SLA.png
Shows that a "ScanIt Support Ticket," that was created and resolved before the SLA modification took place, displays information based on SLA goals that do not exist anymore.
Issue with correct SLA/png
Shows what I expect to see on all "ScanIt Support Ticket" issues, even historical issues. You can see that the SLA is set to a 9 hour goal like how it is configured in the Service Desk SLAs for the project.
- duplicates
-
-
- Closed
-
- mentioned in
-
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page")
Page
Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
This works as expected
I've written a rather long answer in
JSD-358, but let me add a couple of comments on the scenario mentioned in this issueThere is a distinction between the "elapsed time" measurement and the SLA result. The elapsed time measurement in the reports always reflect current time metric/SLA configuration, that is, if you change the start/stop/pause configuration or the goal calendars, issues from the past and present alike will use that now current information to calculate the average.
The SLA outcome on the other hand always only applies to ongoing issues. If an issue started/stopped in the past it will never be updated to the new configuration. Hence your past SLA showing 240h as a limit is correct.
On the other hand, we update all SLAs for "ongoing" issues to reflect the now current configuration. This means, if you change the start/stop trigger configuration, SLAs might disappear or appear for some issues, because they might now be in an ongoing cycle while they weren't under the previous configuration. I've elaborated more in
JSD-358why we don't recalculate SLA outcomes for past issues.Use case wise we imagine the SLA reports to be used to see how the team did/does according to the SLAs as active at the time they worked on issues (hence updating past issues would falsify these reports). The elapsed time (Avg) report on the other hand can be used to see how all issues, past and present, fair according to the most up to date metric/goal calendar configuration. As such, it allows you to find where you would commit to a sensible SLA limit before even setting actual SLA goals.
The documentation cited by you is indeed incorrect as it mentions SLA values to be recalculated, where as this only applies to time metric/elapsed time values and ongoing SLA cycles. We'll get documentation fixed.
Regards,
Michael