Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

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

Tomislav Tobijas
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 19, 2023

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.

image.png

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).

1 answer

1 accepted

0 votes
Answer accepted
Tomislav Tobijas
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 19, 2023

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

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 19, 2023

Hi @Tomislav Tobijas 

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 19, 2023

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).2023-09-19_23-54-26.png

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.2023-09-19_23-54-58.png

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

Like Bill Sheboy likes this
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 19, 2023

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.

Like Tomislav Tobijas likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events