How to Set Due Date Based Off of Original Estimates of All Open Issues

[Matt Steadman]

Hi,

I am trying to build an Automation that will set the Due Date of an Issue to be the Sum of the Original Estimates from a JQL Lookup + the Issues own Original Estimate.

I have built an automation and the screenshot is below of what I am trying to achieve to hopefully make it easier to understand.

Using the automation as I have it now comes up with an error that the I need to enter the Due Date field with an actual date format.

I just can't figure out what smart values I actually would need to put into the Due Date Field to set a date based off the JQL Lookup & the Issues own Original Estimate and have it be an actual date.

Any help with this is greatly appreciated! Thank in advance.

[Trudy Claspill · Accepted solution]

Hello @Matt Steadman 

Refer to this document:

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/

You need to use the plusUnit() function to add the Original Estimate information to a date to get a new date for Due date.

What date do you want to use as the base/start date.

[Matt Steadman]

I would use the {{now}} date as the base. So it'd be to add the combined JQL Lookup Issues Original Estimates Sum & the Current Issues Original Estimate to {{now}}.

[Trudy Claspill]

Are your Original Estimate all in days, or also in hours/minutes? If the sum of the original estimates includes a fraction of a day, do you want the calculation to round up or down?

Instead of using "+" you'll need to use the plus() function.

{{lookupIssues.Original Estimate.sum.plus(issue.Original Estimate)}}

Original Estimates are stored in the database in seconds. If you add that directly to now() that will not take into consideration your working hours per day or working days per week. Do you need the calculation to consider those?

[Matt Steadman]

There could be some Original Estimates that are in hours or minutes. I would want the Calculation to round it up. It doesn't need to take into consideration the working hours per day or working days per week, but, if it could that'd be more beneficial.

[Trudy Claspill]

A straight addition of the original estimates to now() would use the plusSeconds() function:

{{now().plusSeconds(lookupIssues.Original Estimate.sum.plus(issue.Original Estimate))}}

However, Estimate fields take into consideration your working hours. If you have specified 8 working hours in a day, then when you enter an estimate of 1 day  that equals 8 hours rather than 24 hours. So doing a straight addition of the seconds to now() will give you a date you are not expecting. For example.

I enter an original estimate of 3 days

3 days * 8 hours/day = 24 hours

If I add 24 hours to now() that will give me a new date of one day from now rather than the 3 working days I specified for the Estimate.

If you want a more accurate Due date you will need to divide the Original Estimates total by the number of seconds in a working day based on what you have configured  the number of hours in a working day to be for your system. If you have set your system to 8 working hours in a day, then you would divide your original estimate total by  8 * 60 * 60 = 28800. That would give you the number of working days in the total estimate.

{{lookupIssues.Original Estimate.sum.plus(issue.Original Estimate).divide(28800)}}

 In my testing I have the equivalent of 3 days and 4 hours for total estimate. Unfortunately when I use the divide function rather than giving me 3.5 it is giving me just 3. I've tried using the round and the ceil functions and neither is giving me 4, which is what you would want.

So there are still some details I'm trying to work out to get the calculation to consider having some "leftover" seconds/hours in the total estimate.

[Matt Steadman]

Wow thanks so much for all of this. It would have taken me forever to get all that figured out. I have put in your suggestions you have so far and will play around with that and will see if you have any further details you come up with.

In testing it so far the Audit Log is reporting that it runs successfully, however, on the Issue I am testing it on the Original Estimate before running the Automation is 2d and after the successful run, the Due Date isn't showing any edits on it and is unchanged. I have another test issue that is set to an original estimate of 3d as well.

So if it was working as intended the due date should be set for at least 5 days from today.

For your reference this is the smart value I have in the Due Date field on the Automation Rule just in case I have something wrong in it:

{{now().plusSeconds(lookupIssues.Original Estimate.sum.plus(issue.Original Estimate).divide(28800))}}

[Trudy Claspill]

Hello @Matt Steadman 

Did you complete an implementation that works for this? If so, would you share your final results here for the benefit of the community?

If you are still trying to get a successful implementation, please let us know where you are at currently, providing screen images that show your entire rule and the details of each step, and the details available in the rule Audit Log for when the rule runs.

[Matt Steadman]

@Trudy Claspill See below for the rule I am currently using

I tried several different ways to get a smart value similar to this:

{{now().plusSeconds(lookupIssues.Original Estimate.sum.plus(issue.Original Estimate).divide(28800))}}

but couldn't quite get it to work. See my last comment from Oct 17th for more clarification on that.

[Trudy Claspill]

Hello @Matt Steadman 

When trying to debug rules that use smart values it is a good idea to use the Log action to print out the smart values into the rule Audit Log, and confirm that the values are what you expect them to be. In the rule you have above I would print the following:

1. {{lookupIssues.size}}
That will tell you how many issues were found by the Lookup Issues action. The found issues should also be displayed in the Audit log on the right hand side.

2. {{lookupIssues.Original Estimate.sum}}
That will demonstrate that you are getting the value you expect for the sum of the original estimates for the issues found by Lookup Issues. If you are not, what value are you getting? 

3. {{now().plusSeconds(lookupIssues.Original Estimate.sum)}}

You can use the Log action to see what the values would be without actually using the Edit actions. This will help you figure out if the rule is likely to work as expected before making changes to issues.