Looking for ideas on how to put an issue on hold so it does NOT affect the aging of a queue.

[Fringe Technology]

If you have successfully put a jira issue on hold (paused it , suspended it, so to speak), then restarted it, so that the internal aging timer would not reflect the wait time while it was on hold.

For instance, the assignee is waiting for something from someone else, when the information finally comes through and the Jira gets resolved, we don't want it to look like the assignee took all of that time to work the issue. there was some period of time where it was outside of his control.

Please let me know if you have done this or anything similar and how you went baout it. thanks !

[Ramakrishnan Hariharan]

This is the approach I followed.

Create a step called "On Hold". From each step, add a transition to go to "On Hold" step. Have a custom field (On Hold Return Step) to capture the origin step from where it moved to "On Hold". Set the value of this custom field during transition. For example, when transitioning from "Open", set the value of this custom field to "Open". Similarly from each step in the transition to "On Hold", set appropriate value to this custom field.

In the "On Hold" step, add Resume transition for each possible return step (from where it came to On Hold). We have to give different name for each transition as same name will not be accepted. For each Resume transition add a condition to display that transition based on the custom field value. The Resume transition which will go back to Open status will be allowed only if "On Hold Return Step" is equal to "Open".

[Alexey_Rjeutski__Polontech_]

Maybe there is a sence to install some SLA plugin, like https://marketplace.atlassian.com/archive/com.valiantys.jira.plugins.vertygo.jira-vertygosla-plugin that is part of service desk now, or https://marketplace.atlassian.com/plugins/lv.ebit.jira.plugins.sladiator. or Jira ServiceDesk itself

In such situation for our customer we had to write a specific plugin that satisfy all needed business rules.

[Brian Hill]

It's been a while since we've seen an answer posted in here, so thought I'd give a quick mention also of SLA PowerBox which I'm currently evaluating. Looks like it gives good fine grained control over which status to count as SLA-active, vs inactive. Worth a look: https://marketplace.atlassian.com/apps/1215330/sla-powerbox-on-time-service-delivery?hosting=server&tab=support

[Hermann Schenck]

This is a great question and I am surprised Atlassian did not weigh in.

[Joe F. Lee]

we are looking for the same thing, mainly to ensure that reports like "Resolution time" do reflect only the time thatour team has influence over. If we are waiting on parts or input from external sources we surely like to track that time as well, but it should have no impact on KPIs like "Resolution Time".

We are using time tracking, but that measures only the active time spent on a ticket, not really the time it stayed untouched.

Thanks

[Fringe Technology]

Thanks Eirik for your feedback.

Here is a typical scenario of why this is desired.

the employees at this organization are rated on their performance. if a workflow is going to be delayed (for example - a part needs to be ordered), we don't want the length of time that it took the assignee to complete tthe task to be impacted negatively by the wait. It would be desirable to put the task on HOLD until the part came back.

company does not want to use the time tracking feature of JIRA.

[Deleted user]

If you want to know how much time the assignee spent on an issue I suggest enabling Time Tracking. The assignee will then have to enter the hours he or she worked in the Time Spent field. I think this is the only reliable way to get numbers on how much time is spent. You already have pointed out one weakness about relying on the age, but there are probably many more. If the assignee gets sick, or starts progress on Friday afternoon, then what?

I would advice against tampering with the age field anyway. If you are using JIRA to provide a service the one who receives the service will not (should not) care about why something is delayed. Analysing the age of issues is actually one of the core ideas in Kanban (check GreenHopper's Kanban board) for improving the process.

Hope this helps, but it really depends on what you want to achieve. Making something look good, as your question suggests, is not goal I would strive for. Problems should be tackled, not hidden.