Automation Question
Asked by Allan Vaifale:

Hey team,

I have a few automation questions that I need some assistance with, if anyone can help, please.

1. In the first part, our dev team run through 3 statuses before passing it on to QA.  
   The task will start off with being 'ready for development' (to do) \> 'In development' (in progress) \> 'Code Review' . Is there an easy automation that I can create to pre-fill the time tracking field for a story/bug based on the time spent between 'In development' \> 'Code review' ? i.e time starts when the status is updated to 'in dev' and stops when it is then set to 'code review'.
2. The second part, we currently use 'original estimate' for each task, however, we're now required to use a new custom field for this, combined with another new field called 'actual story points'. To avoid any major impact to our workflow, is there an easy automation that I can create that updates our new field to 'match' our entry under he original estimate? I tried but could not find a field that matches 'Original Estimate'.
3. Lastly, (this may be answered by the above), I also need to create an automation that pre-fills the 'actual story points' field based on the time tracking value that is generated from my first question when the status is updated to 'done'.

Sorry, lots of questions there, but I've tied my hand at the automation and cannot for the life of me, get anything to work.


Answers:
author: Bill Sheboy
body: Hi [@Allan Vaifale](/t5/user/viewprofilepage/user-id/4939493)

First thing: for questions like this were you are trying to get rules to work, I suggest posting images of your rule, the audit log details showing the execution, and a description of what does not work as you expect. That will provide context for the community to offer ideas.

Next, when you are unclear if there is a smart value for a field, and the exact syntax for it, please try the information in this how-to article: <https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/>

For your question #1, you could add custom fields to track the data/time of transitions (or call the REST API for the issue history) then then perform math or date/time operations to log the time. I would note caution doing this: are you certain that issues will not remain in a status longer than expected due to delays, such as overnights/weekends? Those could cause inflated values to be logged as work time.

For your question # 2, please try that how-to article to identify the correct smart values to use.

For your question # 3, first get your #1 and #2 cases to work, and then try this one again.

Kind regards,  
Bill

comments: author: Allan Vaifale
body: Hi [@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313) ,

Thank you so much for your reply and the tips for any future questions I may have.

I've made some minor progress with my automation rules.

So far, I have the below rule, which adds 'current date' to the 'start date' field as soon as the status for a task = 'In Development![Snip20221006_7.png](https://community.atlassian.com/t5/image/serverpage/image-id/219435iFB2FEC14B45522D2/image-size/large?v=v2&px=999 "Snip20221006_7.png")

My logic here is, if I have a start date stored somewhere, I could then use that as a starting point to pre-populate a value for time tracking.

Thus, I've created the following automation rule, where I want the system to look at the 'start date' and calculate the difference between that date and the date of when the task is updated from 'In dev' to 'Code Review'

![Snip20221006_8.png](https://community.atlassian.com/t5/image/serverpage/image-id/219436i288CBBF942DDAB03/image-size/large?v=v2&px=999 "Snip20221006_8.png")

The automation works, however, I can't seem to get the calculation right with the time logged. I've tried .seconds, .minutes, .days \& .hours and I still can't get an accurate reading.

The below example task has a start date of 03/10/2022. The status for the task was changed to 'Code Review' on 06/10/2022, so I would've expected to see 3days logged in the time tracking, however, I instead got the below result.

![Snip20221006_9.png](https://community.atlassian.com/t5/image/serverpage/image-id/219437i46B8AEBBF8524F13/image-size/large?v=v2&px=999 "Snip20221006_9.png")

Any suggestions on what I'm doing wrong here, please?


author: Bill Sheboy
body: Two things to help...

The time tracking features use the system settings for working days and hours, so it can help to log as minutes and then let the system do the rest.

Next, when adding to timeSpent, the units of measure are required, such as minutes as "m".

So perhaps try this in the JSON expression:

"{{issue.Start date.diff(now).minutes}}m"


author: Allan Vaifale
body: Thanking you [@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313)

I've made your suggested changes but still no luck :/ A lot better than 3minutes from my first trial run though

![Snip20221007_10.png](https://community.atlassian.com/t5/image/serverpage/image-id/219538i1D77437DF46A4924/image-size/large?v=v2&px=999 "Snip20221007_10.png")![Snip20221007_11.png](https://community.atlassian.com/t5/image/serverpage/image-id/219537iC1B1CCAC269E30EA/image-size/large?v=v2&px=999 "Snip20221007_11.png")For context, our ''ideal day'' equates to 8hrs and the current workday setup looks like the below for this specific project:

![Snip20221007_12.png](https://community.atlassian.com/t5/image/serverpage/image-id/219539i050F30C7B99222FD/image-size/large?v=v2&px=999 "Snip20221007_12.png")

Do you have any other suggestions on what I could try out, please?


author: Bill Sheboy
body: A couple of other thing to try could be informed by first writing the value of the Start Date and Now to the audit log in that rule...

Do you have people in different time zones transitioning issues? If so, you may need to convert both Start Date and Now to the same time zone before performing the difference so you can see the results in the same frame of reference.

Next, I believe Start Date is a date field and not a date/time field like Now. And so you may need to perform a diff on just days, and then multiple to get the minutes. Otherwise I believe the "time" for Start Date will always be the first second of the day.


author: Allan Vaifale
body: Perfect, it looks like I managed to get it working using "{{issue.Start date.diff(now).days}}d" - Thanking you!

To finish up my automation rule, I now need the tracked time value to add to our story points.

I am hoping I can autofill the story point value when an issue is transitioned to ''approved'', but am not quite sure the best approach to achieve this or how to run the correct calculation so that say, 2days and 4hrs logged work equates to 2.5 story points - Would you have any recommendations on a rule setup for this, please?


author: Bill Sheboy
body: Such a rule could be a variation of what you have already done, just using the sum of the logged work with math (or conditional logic) to update the other fields, however...

I wonder why one would do this. Story points are usually a relative measure forecast to help with sizing work, potentially in support of sprint planning. Equating them to an actual hour measure may be mixing units of measure.

Why not just use the effort hours by themselves (ignoring story points as an estimation statistic for Jira), as that appears to be what the team is using to track progress?


author: Allan Vaifale
body: Thanks [@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313) !

Our organization has two-story point fields (Estimated Story points and Actual Story points).

These are now mandated required fields, however, a few projects within the org. do not use this logic, so the idea for automation was to have a time tracking values pre-fill the ''actual story point'' value so that for reporting, management can cross-compare the 'estimate' to the actual time for the dev work and our dev teams aren't inclined to change up their workflow whilst still providing the info that head office needs.

1 Story point equates to 1 ideal day, so 1day logged with time tracking would result in 1 story point being added.

I hope that clarifies a bit of the business logic behind this one