Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Tracking an issue

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?

2 answers

1 accepted

0 votes
Answer accepted

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 Community Leader Apr 16, 2021

Glad you found a solution that works for you!!  

Like Rahul Gupta likes this
1 vote
Chris Buzon Community Leader Apr 12, 2021

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



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

Like Chris Buzon likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you