Automation to update Due Date based on Start Date + Original Estimate --Failing

[Jennifer Baum]

I found this article explaining how to update the due date based on a variable: https://confluence.atlassian.com/cloud/automate-due-date-of-an-issue-from-original-estimate-1021245282.html

I have tried this multiple ways and I get the due date to UPDATE, but its not the correct value.   Below is the workflow:

After I enabled the automation, I ran a test and its is updating the Due Date with the incorrect value -- it should be adding 6 days to the Start Date but its only adding 1 day:

Any help is appreciated

[Jennifer Baum]

ignore

[Bill Sheboy]

Hi @Jennifer Baum 

A couple of things to check...

Please write your created variable to the audit log to see if it contains what you expect.

And, please remove the .jiraDate from the end of the expression editing the Due Date.  I have no idea why that would be needed.

Kind regards,
Bill

[Jennifer Baum]

I removed .JiraDate from the end of the expression When I run it now, it doesn't update the due date at all but shows success in the logs:

[Bill Sheboy]

Would you please add a write to the audit log, after the Create Variable, to log what value it contains?  Then post an image of that audit log entry when the rule runs.

I also suggest trying to perform that due date set in one step:

{{issue.Start date.plusBusinessDays(issue.timetracking.originalEstimateSeconds.divide(28800))}}

[Bill Sheboy]

I see the problem: you are trying to use the Original Estimate as seconds, but that is 0m on your example issue in the screen image.  Please check the Original Estimate for the issue.

I just tested the rule from that article myself and it works as expected.

[Jennifer Baum]

@Bill Sheboy - so the Original Estimate can be anywhere from 1-3 days for a subtask.  I was using 6 days to test how it handled weekends.

What are you wanting me to check on the Original Estimate?  It will always be in days.

Can you send a screenshot of the workflow?  I'm not sure if you want me to remove the variable and change the Edit Due Date function to 

{{issue.Start date.plusBusinessDays(issue.timetracking.originalEstimateSeconds.divide(28800))}}

or something else.  Again, thanks for your help. 

[Bill Sheboy]

Hi, and sorry if I caused confusion.  To clarify what I asked/observed:

• In your screen image of the issue, the Original Estimate field appears to show "0m" and another value of "1w 1d remaining" above it.  How can that occur for a single issue? 
• The calculation you are trying to use is only based on Original Estimate, and so if the value is 0m that would explain why the field is not changing.

• Next, please try writing the value of your created variable to the audit log, run the rule, and describe what you see.  That will confirm if the problem is with the created variable calculation, or something else.

[Jennifer Baum]

Ok, I see what you mean.  We set the estimates on our subtasks in the Advanced Roadmap which does NOT update the Original Estimate on the subtask but does add the value to the Time Tracking field.

This being said, I might need to change value of Original Estimate to Remaining Estimate?

{{issue.Start date.plusBusinessDays(issue.timetracking.originalEstimateSeconds.divide(28800))}} ??

Also, are you saying that I should not create a variable and just do the formula in the Edit Issue action?

[Bill Sheboy]

That time tracking field (and advanced roadmap) differences would explain why the calculation is not changing the date as you expected.

If you used remaining estimate instead, that would make the due date a moving value, correct?

Your next steps may depend on what you are trying to do.  Please pause to consider if you want to:

1. forecast due date at a subtask level
2. forecast due date at a higher, parent issue level (e.g. rolling up the subtask estimates)
3. something else?

If you want #1, try to find a way to set the Original Estimate so it is a stable initial value.  Then your rule will work as expected.  You can choose to continue with the created variable or do the calculation in one step, as I described.

If you want #2, your rule(s) will need to change to account for changes to parents and children such that the values roll up.

[Jennifer Baum]

@Bill Sheboy 

Overall, I have 2 triggers. 

1. Updates the start date and is working successfully. 

2. Update due date - failing

 It would be great to combine them into trigger to update both fields when transitioned:

     WHEN an issue transitions to In Progress

      AND Issue Type = Sub-task

      AND Start date is empty 

     THEN update Start Date = Current date {{now.PlusBusinessDays(0)}}

      AND update Due Date =  Current date + Remaining Time Estimate based on business days

 Is this possible?

[Bill Sheboy]

Yes, you probably can do that in one rule.  Start with what you have and substitute in the other time tracking field.  That will solve other challenges by doing this in one rule.

I recommend considering how you want to this to work if something moves backwards in flow (e.g. from a "testing" status back go "in progress") to avoid changing the dates when not desired.

[Jennifer Baum]

OK, I was able to make one trigger to update both. Thank you for the help.

Here is the view of the new trigger that will updated the Start Date and Due Date when a sub-task gets moved to In Progress.

[Bill Sheboy]

Well done!  Did it update the Due Date as you expected?