Modify Original estimate from the Plans Timeline

[Filippo Balducci]

Hi all, 

I'm currently trying to understand how the Plans Timeline works. As far as I understand, changing task dates by dragging its timeslot in the Timeline DOES automatically change it in the Project > myProject > List, but the Original Estimate is unchanged. So you can have a task that takes 16 days in the timeline, but 3 days in the task list.

Here's an example:

I modified task 2.3 dates in the Timeline view, so it takes 17 days to complete.

Here's what it does in the task list:

As you can see, the dates are correct (they are the same), but the Original estimate is not (17 days vs 3 days). 

So I figured I need a rule that triggers when either of a task dates are modified, and calculates the Original estimate by subtracting the Planned start to the Estimated end (two date picker custom fields). 

I tried to make this with a rule that triggers when Planned start and Estimated end are modified (either manually by me or automatically by the Timeline changes), checks the dates are not empty and then make the subtraction with this:

Original Estimate
{{#=}} (({{issue.customfield_10176.diff(issue.customfield_10177).seconds}}) / 3600 ) {{/}}

with customfield_10176 and customfield_10177 being Planned start and Estimated end respectively.

This gave weird results at first, as it returned the difference between Dec 10th and Dec 11th (1 day) as 24 minutes, Dec 12th (2 days) as 48 minutes and so on, so I tried to solve it multiplying the result by 20 (24 minutes * 20 = 8 hours=1 business day), but this causes problems too (results now overflow). 

How can I calculate the difference between two dates correctly? Or is there another way to link the Timeline modifications to the project task list successfully?

[Bill Sheboy · Accepted solution]

Hi @Filippo Balducci -- Welcome to the Atlassian Community!

For a question like this, context is important for the community to help.  Please post the following:

• an image of your complete automation rule,
• images of any relevant actions / conditions / branches, and
• an image of the audit log details showing the rule execution.

Until we see those...

Based on what you show for that smart value expression example, the diff is returning 86400 and the division by 3600 then returns 24 (which is in hours, and it is just an integer, with no other information about units).

I hypothesize you are not providing units of measure when you set the Original Estimate value.  When setting the time tracking fields, I recommend always adding the units of measure to explicitly manage the behavior.

Please try adding an h after the expression, and then adjust your rule accordingly if you want the values in "business hours":

{{#=}}{{issue.customfield_10176.diff(issue.customfield_10177).seconds}} / 3600{{/}}h

Or with an inline math expression like this:

{{issue.customfield_10176.diff(issue.customfield_10177).seconds.divide(3600)}}h

Kind regards,
Bill

[Trudy Claspill]

@Filippo Balducci 

Welcome to the Atlassian community.

Also, note this is a false statement:

As far as I understand, changing task dates by dragging its timeslot in the Timeline DOES automatically change it in the Project > myProject > List

Changes made in a Plan do not automatically update the underlying issues. You must use the Unsaved Changes button in the upper right corner to review the changes you have made in the Plan and save the changes of your choice to their underlying issues/projects.

[Filippo Balducci]

Hi Trudy, 

yes, I didn't mention it, but this is all assuming I'm updating the changes in the Timeline, since if I don't do that the changes would be lost. After I do that, date changes are copied in the tasks list too, but not the Original estimate.

[Filippo Balducci]

Hello @Bill Sheboy, thanks for the reply!

The inline math expression with the added h at the end worked for me:

{{issue.customfield_10176.diff(issue.customfield_10177).seconds.divide(10800)}}h

It returns the correct number of hours between two dates. Jira already accounts for business days, so if the calculated difference in days was 1 day = 24 hours for example, Jira would automatically transform it into 3 business days (24/8 hours = 1 business day). I solved this easily dividing by 3600*3 instead of 3600.

Here is a final overview of my rule:

Thank you for the help, have a great day!

Edit: it occurred to me that Jira also transform 5d = 1w, so if you change the date to Dec 10th to Dec 17th, instead of 5 business days Jira returns 7 days (rightfully so), which translates into 1w 2d of business days. Is this managable in some way?

Edit 2: I thought I found a solution:

{{issue.customfield_10176.diff(issue.customfield_10177).businessDays}}

this should return the difference in business days, and I think it works, but could it be the Original Estimate is in minutes? Because it returns the correct number, but not the correct unit (minutes instead of days).

[Bill Sheboy]

Well done solving the last part!

There can be challenges when mixing date math and time tracking values in rules...

People normally enter time tracking as a "working time" forecast.  When performing math on values such as Original Estimate, Jira uses its definition of "working time" only for logging time and pretty printing, such as in human-readable, weeks, days, hours, etc. (i.e., Monday to Friday, 9am to 6pm)

But when using hours, minutes, seconds, or milliseconds, the time tracking is providing just a number, with no information about days of week or working schedules.

The impact is when performing a diff() on dates and then adding time tracking values, one may need to manually account for the differences between a 24h day and a 9h day.