Tracking an issue

[Rahul Gupta]

We have tickets which often start in one queue and then move to different queues before either getting resolved or ending up in a product "backlog". How do you effectively track time it took for the ticket to reach a final state? Each time the ticket is moved to a new queue, the history from the previous queue is lost along with the time spent details.

Also, I have tried some plugins like time to SLA and Time in Status but they dont seem to solve for the above. 

I am thinking maybe I can use a label as the ticket gets logged in the first queue and then follow it as the issue key keeps changing but yet again, i will lose history on the ticket as soon as its moved.

Any ideas or has someone solved for this before?

[Rahul Gupta · Accepted solution]

So we came up with a solution based on your recommendation.

When the ticket comes in, we will apply a label e.g. "ToBeTracked".

We are now adding 2 fields - start time and end time - which will be enabled on all PROJECTS where this ticket can potentially go to. I think this was the key step - knowing all possible PROJECTS the ticket can end up in. And we already know which is the first Project the ticket is created in. 

All those projects (where the ticket can possibly end up) will have automation in place. The start project will update the "Start time" field and the last project where this ticket (identified using the label) is resolved, will update the end time field. 

Using the label, start time and end time, we can now compute the time it took. 

Thanks again for your help. 

[Chris Buzon]

Glad you found a solution that works for you!!  

[Chris Buzon]

Hey Rahul,

There are a couple of ways you could try to do this - but the devil is in the details, of course.  My company tracks a couple of key ticket events as Timestamps in custom fields. 

using a post-function (I suggest JMWE app) we use the jira system timestamp to populate a custom field with said timestamp:

For example:
Backlog -> Todo transition will timestamp a  "Todo Timestamp" field when that transition happens.
Todo -> In progress will timestamp a "In Progress timestamp" field when that transition happens
..etc

We then pipe that info into our data lake and do some fancy SQL work with it, giving us a metric similar to what you're looking for.

Things to know:

- This is kinda like hardcoding a workflow, and can incur a maintenance cost and setup cost for new projects.
- Teams may not understand the value of updating tickets in a time-sensitive manner - so if they forget to move the ticket, your timestamp value may be wrong.

- This works agnostic of actual workflow, if you're using statusCategory correctly.
- This won't work in exactly this way for a next-generation project, but using Jira automation you could do the same thing.

- Moving between PROJECTS may complicate this, especially if the statuses in question are hit multiple times (the values could be overwritten, if you don't specify fallback logic).

[Rahul Gupta]

Hi Chris,

Thanks for the prompt response and the suggestion.

I like your idea and what you are saying in the end is correct - our key problem is moving across PROJECTS and there are multiple projects with the same statuses. 

Let me run this by our admin. See if he can come up with something. 

-Rahul