Calculating Original and Remaining estimates on parent tasks (above Epic level)

[Tomislav Tobijas _Koios_]

Hi,

We have a use case where it is required to calculate Original and Remaining Estimates on parent tasks based on the changes on child issues.

For example, we have the following hierarchy:

• PMO Initiative
  • PMO Epic
    • PMO Story
      • Epic (this is 'standard' Jira Epic)
        • ....

Note that we're looking only at first three levels - so, "PMO Initiative", "PMO Epic" and "PMO Story".

ℹ️ Additional info: Original Estimate can be set on any issue type/hierarchy level. For example, you could set an estimate on PMO Epic as well as on PMO Initiative.

The desired result is that whenever someone sets/changes Original and Remaining Estimates on child issue, the values are automatically 'added' to the parent issue.

For example, let's say we have the following values for PMO Epic:

• Original Estimate: 1w
• Remaining Estimate: 1w

When someone adds PMO Story below this Epic, and the PMO Story issue type has the following values:

• Original Estimate: 1d
• Remaining Estimate: 1d

The Epic would have 1w 1d values for both Original and Remaining Estimates.

The same should work whenever someone logs time and the value for Remaining Estimate changes.

So, what we managed to get so far is this calculation for Original Estimate by using Time Tracking trigger and {{fieldChange.to/fromString}} smart value. This smart value always gets values for Original Estimate and we got stuck on how to get Remaining Estimate from it.

Any chance you could build {{fieldChange.remainingestimate.from/toString}} or something like that?

Also, if this isn't possible, is there any workaround for it?

ℹ️ One note - we're using linkedIssues relation instead of parent link as relations are created in WBS Grantt-Chart but we'll try to get it working with standard parent-child relation as well (to be tested).

[Tomislav Tobijas _Koios_ · Accepted solution]

@Bill Sheboysorry to drag you into this, but is there any chance you know this one?

[Bill Sheboy]

Hi @Tomislav Tobijas _Koios_ 

First thing, I am using Jira Cloud and not Server or Data Center.  And so please confirm my ideas by checking if you have these smart values available using this how-to: https://confluence.atlassian.com/automation/find-the-smart-value-for-a-field-993924665.html

Next thing: for the hierarchy you describe, have you thought through the plan of how to handle someone changing values in the middle, like for an Epic?  Should it recalculate the values from the child stories, and then update the parent Initiative?  Something else?  I believe this complexity is why many use marketplace addons rather than the built-in time tracking features.

Anyway...back to your question...

When I check for Jira Cloud, the Remaining Estimate (and total) fields' smart values are:

• "Remaining Estimate" and timeTracking are the same
• aggregatetimetracking (which is the sum field of timetracking)
• remainingEstimate is the item-level value in the entry for time tracking logging

What I do not know is if these all have changelog / fieldChange entries rules can access.  There is a "Work Logged" trigger and relevant smart values which you can use for entry creation: https://confluence.atlassian.com/automation/jira-smart-values-issues-993924860.html#Jirasmartvaluesissues-worklog and https://confluence.atlassian.com/automation/jira-smart-values-issues-993924860.html

I recommend doing some small scale, exploratory testing first to learn what is possible.  Only then invest in trying to create rules around these fields.

Kind regards,
Bill

[Tomislav Tobijas _Koios_]

I was just working around with those (mostly with {{fieldChange}} smart value and actually I managed to get the result.

Firstly I've checked what {{fieldChange}} smart value returns and inside the results, you can check which field was changed. Regarding Time Tracking trigger, it can be either timeestime (which is Remaining Estimate) or timeoriginalestimate (which is Original Estimate).

Based on that, you can get appropriate values by using {{fieldChange}}{{toString}} or {{fieldChange}}{fromString}} and these can be manipulated later in the rule by using standard/math expressions.

So, I've added few If/Else blocks that have conditions based on mentioned smart values (depending if we're looking at change on Original or Remaining Estimate) and then just added an action that does a specific calculation.

In any case, I just needed to log {{fieldChange}} smart value first to see what I could do with the provided results.

Additional note after latest tests - {{fieldChange}}{{fromString}} would, for example, get previous/old value from one of those fields. This way of implementation works only if one of the fields is changed/updated. If both fields are updated at the same time (e.g., via Edit screen), you could, potentially, use something like this:

• {{#changelog.timeestimate}}{{fromString}}{{/changelog.timeestimate}} - for Remaining Estimate old/new values, and/or
• {{#changelog.timeoriginalestimate}}{{fromString}}{{/changelog.timeoriginalestimate}}

This should also cover the case if both field values are updated at the same time (although I would probably need to test it out properly).

Regarding the hierarchy - yeah... There are still many cases that we haven't considered. I would say testing is in the early stages but we'll definitely add that example you mentioned on the list too.

Anyway, sorry for bugging you @Bill Sheboy - should have just performed more tests before posting it here. But hey, maybe this will help someone else who stumbles on this.

Regards,
Tom

[Bill Sheboy]

No problem; glad to try to help.  And as you note, the info you shared will help others who try to investigate these fields/scenarios.