How to create an automatic rule that will update ticket time fields so that time can be tracked

[Yana Nikolayeva]

Hi Team, 

I want to create an automatic rule that will update ticket time fields so that when ticket status will change from 'Selected for development' -> 'In progress' start time set to current time and when ticket transition from 'In Progress' -> 'Done' time updated as completed tasks. 

I was trying to create a rule with parameters based on ticket Transition status, but was not sure what time fields need to be updated; what custom query code to use to update date time fields?

Can someone help? 

Thank you in advance

[Emre Toptancı _OBSS_ · Accepted solution]

Hello @Yana Nikolayeva ,

If you are interested in a ready built solution, our team at OBSS built Time in Status app for this exact need. It is available for Jira Server, Cloud and Data Center.

Time in Status allows you to see how much time each issue spent on each status or assigned to each assignee or group. The app shows the total time spent in a status so reworks and reopens are calculated correctly too.

You can combine statuses into consolidated columns to see metrics like Cycle Time or Lead Time. Also can calculate averages and sums of those durations grouped by issue fields you select. (For example see the average InProgress time per project and per issuetype.). Your question indicates that you plan to use dates for calculating status times but if you need the dates anyway, Time in Status can also list status entry/exit dates.

The app has custom calendar support so you can get your reports based on a 24/7 calendar or your custom business calendar. (This one is important because a 24/7 calendar in most cases shows misleading data. For example an issue created at 16:00 on Friday and was resolved at 09:00 on next Monday seems to stay open for 2,5 days but in terms of business hours, it is only a few hours. You can see this using Time in Status by OBSS.)

Using Time in Status you can:

• See how much time each issue spent on each status, assignee, user group and also see dates of status transitions. Get metrics like Lead Time or Cycle Time.
• Calculate averages and sums of those durations grouped by issue fields you select. (For example see average InProgress time per project and per issuetype.)
• Export your data as XLS, XLSX or CSV.
• Access data via REST API.
• See Time in Status data and charts for each issue as a tab on issue view screen.

Timepiece - Time in Status for Jira

EmreT

[Yana Nikolayeva]

Thank you EmreT, it is good to know. I will keep it in mind

[John Funk · Accepted solution]

Hi Yana - Welcome to the Atlassian Community!

Can you share a screenshot of the rule you have so far? 

Are doing an edit to the issue set the start time to now()?

[Yana Nikolayeva]

Was  trying to attach file unsuccessfully so will describe my rule setting:

Rule Set Start Date automatically when issue moved into status 'In Progress'

1. When issue transitioned

FROM Selected for Development , Backlog

TO

In progress

2. THEN

Edit issue fields

Start Date

{{now.dayOfMonth}}

----------------------------

I am not sure if Start Date is a right field to update in this case, same about end date. Should I update some other fields?

[Yana Nikolayeva]

[Yana Nikolayeva]

Finally was able to upload. 

Please do not pay attention to  Rule tag ‘Disabled’ as after I did get any result I set it off.

[John Funk]

What if you just used {{now()} 

[Bill Sheboy]

Hi @Yana Nikolayeva 

We did the same thing, and we added additional custom fields to track cycle time for various phases of work: dev cycle time, test cycle time, and build cycle time.

Three things to watch for when using this technique: rework, cloning, and rule execution order.

• When you have rework, decide whether or not you want to "restart the clock" if an item moves back into in progress.  If you do not want to, add a condition to only set the start time when it is already empty.
• Cloning.  We had to add a clean-up rule to reset the values when an issue was cloned as new.
• Regarding rule execution, the order of rules is not rigid...so, the triggers are the key.  If you plan to compute something (like lead time), ensure that you have all of your data before the trigger occurs.  We solved that by using specialized comments to flag when it was time to compute things like cycle and lead time.

Best regards,

Bill

[Yana Nikolayeva]

Thank you for advice John_Funk, unfortunately  {{now()}  does not work.

I will look into your suggestion Bill_Sheboy, thank you very much for details.

[Bill Sheboy]

I believe that is missing one brace at the end and has extra parenthesis.  Please try:

{{now}}

[John Funk]

Yes, sorry about the syntax error. 

[Bill Sheboy]

I added these suggestions to help with that in the future.  :^)

Validate automation rules before saving

https://jira.atlassian.com/browse/JSWCLOUD-20445

https://jira.atlassian.com/browse/JRASERVER-71196

[Mehmet A _Bloompeak_]

Hi @Yana Nikolayeva ,

You can use Status Time add-on. It generates time spent on each status based on a calendar(7/24 or working hours).

If you are looking for a free solution, you can try Status Time Free. 

[Zoryana Bohutska _SaaSJet_]

Hi @Yana Nikolayeva 

Also, you can try other solutions from Atlassian Marketplace, like:

- Time in Status for Jira Cloud by SaaSJet - lets you view each status duration data and time in groups of statuses. All reports from add-on available for chart view and as the gadget for Jira dashboard. 

- Time Between Statuses - calculate status to status time. It lets customize the calculation by setting start/pause/stop statuses and by selection first/last transition to/from status. Additionally using this plugin you can set warming time limits and notification for exceeded issues.

With all this add-on you will be able to monitored Cycle and Lead time.

Hope it helps