Sum up Original estimation to Start date

[Vitor Seabra]

Hey folks! I need some help here once I can't figure out how to keep on going with this issue.

I have the following fields and I just want to sum them up using an automation with Jira Smart Values:

• Original estimation
  • Native field
  • Type: Time tracking (I want to estimate as business days)
  • Ex: 2w, 3d, 4h....
• Start date
  • Custom field (but comes native)
  • Type: Date picker
  • Ex: 04/04/2023

The result must be the Due date field based on their sum:

• Due date
  • Native field
  • Type: Date picker
  • Ex: 04/18/2023

So, if I logged 3d in the Original estimation field and then the Start date is 04/06/2023, the Due date field should be automatically calculated as 04/10/2023 (once it is taking consideration business days).

Can anybody help me with the right Jira Smart Values expression?

Thank you in advance and I hope you are having an amazing day!

[Trudy Claspill · Accepted solution]

Hello @Vitor Seabra 

I haven't worked out all the details but I think the smart value you need for setting Due Date is:

{{issue.Start Date.plusBusinessDays(<number>)}}

plusBusinessDays assumes that business days are Monday through Friday.

<number> would be your Original Estimate value converted to days.

In my system Original Estimate is stored in the database in seconds, so I have to divide by 3600 to get hours. You would need to then divide by the number of working hours you allocate per day.

I know that is defined in the system Time Tracking settings, but I haven't tried to figure out if the value can be pulled directly from there into an automation.

So, let's say that my original estimate is 3 days. And I have 8 working hours per day.

- In the db that is stored as 86400 seconds

- Divide 86400 by 28000 to get 3 days

- Confirm that my estimate is >= 1 day.

-- If it is not, then Due Date = Start Date

-- If the original estimate is >= 1 day, then divide original estimate hours (24) by 8. Use the Ceil function to round that up to the nearest whole number, in case it is a fraction.

Then plug that number in to the smart value at the start of my answer.

Caveat:

I was testing this out using original estimate values that were not whole days expecting the Ceil function to round up. If my original estimate was 2.5 days, I expected Ceil to give me a value of 3. It didn't. Instead it gave me a value of 2. In fact using the "divide" function returned 2 rather than 2.5. I had to use the division math operator to get the result of 2.5. So, from that I'm not yet sure how to force a round up for an original estimate that includes 1..n whole days plus some fraction of another day.

Below is an automation rule I created just to run the calculations and print the output to a the rule's Audit Log.

[Vitor Seabra]

Hey Trudy! Thank you so much for your response. I guess I'm about to create a number custom field to replace the Original Estimate. It looks quite complex and a number field would simplify it. Do you think that it would work?

{{issue.StartDate.plusBusinessDays(issue.NewNumberCustomField)}}

[Trudy Claspill]

Are your Original Estimates/NewNumberCustomField always going to be in whole business days? Will your estimates never include partial business days or less than a whole day?

[Vitor Seabra]

Always full

[Trudy Claspill]

I would not go the route of adding another custom field.

If you implement work logging, automatic recalculation of Remaining Estimate will be based on the value of the Original Estimate field.

There is a calculated field Work Ration that can be displayed in search results that shows the percent of Original Estimate that has been consumed by Work Logged.

Neither of these would make use of your new custom field.

If you intend/expect the Original Estimate will always be only full work days then for the rule you construct you don't necessarily need to implement all the additional checking I mentioned on the value of Original Estimate. You just need this smart value for setting the Due Date:

{{issue.Start Date.plusBusinessDays(issue.original estimate.divide(28800)}}

Everything else in my rule was just logging values to the Audit Log to confirm what values where being used.

For your rule you would also need to decide on when to trigger it:

- when a new issue is created

- when the Start Date is changed

- when the Original Estimate is changed

After the trigger you may want to add conditions to confirm that neither the Start Date nor the Original Estimate fields are empty.

Then you would use an Edit action to Edit the Due Date field, setting its value to the above smart value.

[Vitor Seabra]

Yes! I'm using exactly the trigger: Start Date changed.

I just recorded a Loom video to better show to you. I hope that it helps!

Automation - Jira - 5 April 2023 (loom.com)

[Trudy Claspill]

Hello Vitor,

I've watched your video.

Whenever a rule does not do what you expect, the first thing to check is the Audit Log.

The Audit Log will show an entry for each time you have published the rule (Status = Config Change) and each time the rule has been triggered. Look here to first confirm that the rule was triggered.

If the rule was triggered there will be a status for the execution (i.e. Success, No Actions Performed, Some Errors). You can click the Show More link to the right of the entry to see the details of the rule execution.

In this case I suspect the rule may not have been triggered.

When you create a new rule, on the Rule Details there is a check box that is checked by default.

In your case you are using another Automation Rule to set the Start Date. And this Due Date rule is triggered when the Start Date is changed. This Due Date rule needs to have this box unchecked so that the Due Date rule can be triggered by the other rule changing the Start Date.

Let me know if that resolves this final issue.

If I am wrong and your Due Date rule is getting triggered, then please share a screen image of the Audit Log for when the rule executed.