How to sum up logged hours using automation in Jira Cloud

[#1]

Hi Atlassian community,

Sherry here, one of the engineers from the Jira automation team!

Lots of people have been asking about one of our new features which allows you to:

• Sum up logged hours of all issues in an Epic

• Sum up remaining estimates or original estimates in all subtasks and set it to the parent task.

• And lots more

You can now sum up numerical fields such as Story points and worklogs using Jira automation. If you want to learn how to do it, check out this blog. In this post, I just wanted to take the chance to answer some common questions that have popped up in recent webinars since users have started experimenting with it.

How to use sum to add work logs?

Many would think to use simply sum over log field like “Original Estimate“ (as we use it to sum up “Story points”) like below

{{issue.subtasks.Original Estimate.sum}}

But this gives outputs not as expected.

Why is it printing minutes instead of hours?

The short answer is that the default time tracking unit in Jira is minutes and this will sum up the time in SECONDS, so a smart value like below will print off a larger number than you might expect.

Sum function works for "numbers" but since time tracking is done in either minutes or hours or days, summing up tracking fields starts giving undesirable output.

How to use it actually

First of all check the default time tracking unit in your Jira instance which would be MINUTE, by default, for most of the people

https://YOURINSTANCE. atlassian.net/secure/admin/TimeTrackingAdmin.jspa 

If it is set as minute, divide the sum by 60 to get hours/days

{{#=}}{{issue.subtasks.remaining estimate.sum}} / 60{{/}}

If it is set as hour, divide the sum by 3600 to get hours/days

{{#=}}{{issue.subtasks.remaining estimate.sum}} / 3600{{/}}

Let’s take a look at a sample rule in context.

Example Rule

It updates ‘Original Estimate’ of parent if any child issue/task is created.

Use Cases

1. This feature can be used to track total “Remaining Estimates“ or total “logged“ work in an Epic or any Parent ticket.

If you have any questions, please feel free to comment below 🙂

[Maria Yacoub]

Hello,

To use the  total "logged" work, do we have to use the Work log trigger or can we call the timeSpent smart value and do the same thing than in your example , meaning : 

{{#=}}{{issue.childissue.timeSpent.sum}} / 60{{/}}

 In any of this case, can you show me how to make it please ? 

Here is my use case : 

I have an Epic "My Epic" , which has a task "My task", which itself has a subtask "My subtask".

Here is the scenario I would like to have :

A user logs his hours in the time tracking " Time spent" field in the issue "My subtask"

=>  automatically update the timeSpent in "My task" and "My epic"  by adding the time spent that has just been added on "My subtask".

Thank you in advance,

Maria 

[Maria Yacoub]

Hello,

I find the solution.

I created two rules using "Work logged" trigger. The first rule will update the timespent of "My task" and the second will update the timespent of "My epic".

I just had to Allow rule trigger in Rule details.

See https://community.atlassian.com/t5/Marketplace-Apps-Integrations/Can-I-use-automation-rule-to-trigger-another-automation-rule/qaq-p/912010

[Maria Yacoub]

Hello @Sherry Goyal ,

I am trying to set the remaining estimate of an epic equal to the sum of the remaining estimate of its child issues (ex: story). I have done this for the subtasks (remaining estimate of Story = sum of remaining estimate of its subtask) and it is working correctly, but I am not having the same thing for the epic.

Here is what I test for the remaining estimate of epics : 

And : 

Nothing works....

If you have a solution, I will be happy to know it ! 

[Sherry Goyal]

Hello @Maria Yacoub 

Thanks for writing your query to us and explaining your case.

I must say doing things for epic is not so easy as there is no way of accessing epic's stories directly through smart values, at the moment( we do have it our backlog).

But I can say there is a way out.

I used following to set estimate:

{{#=}}({{fieldChange.to}} - {{fieldChange.from}} + {{issue.original estimate}})/60{{/}}

 And my rule looks like this:

So basically, what I did is if any time tracking value changes in child issue/subtask/story and it has an Epic as a parent, I find the difference in the "original estimate" field of triggering issue(in this case story inside epic) and add it to epic's "original estimate".

Please let me know if this workaround works for you.

Cheers,
Sherry

[Bob Ramza]

How would you go about this automation at a project level for all tasks & sub tasks?  I'm trying to automate some of our reporting processes, and the total logged hours per project would save a bunch of time across the org on a weekly basis.

[Sherry Goyal]

@Bob Ramza This ask is currently in our backlog where we want to sum up story points at sprint level and shall be picked up soon.

• https://codebarrel.atlassian.net/browse/AUT-1966

Thanks for writing!

Cheers
Sherry

[Bob Ramza]

Thank you, Sherry! 

I've shared the product backlog, and I will be tracking this with our practice lead.  We'll be thrilled when this is picked up.

[Anita Kalmane]

Thanks for the blog post, @Sherry Goyal !

I'm looking for a way how to send an automatic Slack message every week which sums the hours logged on a certain project in the week before (just total sum).

How would that be possible? I fail to find this information online :(

[Sherry Goyal]

@Anita Kalmane Thanks for writing to us. I think by project you mean by a particular sprint/board present in a project. That work is still in progress. I will update this article as soon as the feature is shipped.

Thanks
Sherry

[anthony_butler]

@Sherry Goyal I am trying to do something very similar to this, and wonder if you can offer any assistance?

I have two projects, Incident Management(IMT) and Problem Management(PMT). In the Incident Management project I have a field titled 'Incident Cost - Lost Agent Hours' that we fill in with a numeric value at the end of every incident to reflect how many hours it has cost us from an end user CS agent perspective. We then link our incidents to problem tickets in the Problem Management project. One problem can have multiple incidents linked to it if necessary. 

I would like to be able to set up a rule or automation that takes the 'Incident Cost - Lost Agent Hours' value from the incident tickets and returns a sum of them on the problem ticket. I would like this to update each time a new incident ticket is linked to the problem ticket so as to show a running total. For example:

Incident ticket 123 has a value of 10 agent hours, when it is linked to problem ticket 123 the value of 10 is shown in the agent hours field.

Incident ticket 345 has a value of 20 agent hours and is subsequently linked to problem ticket 123. The value in he agent hours field should now read 30. 

The way in which these issues are linked is always the same IMT is linked to PMT by using 'is linked to problem ticket' which subsequently shows as 'is problem ticket for' PMT to IMT.

I've tried {{issue.Incident Cost - Lost Agent Hours.sum}} but this doesn't add up the fields and instead removes anything that is added into the field on the Problem ticket. 

Any suggestions at all?

[david catriel]

Hello all.

We're also on the lookout for the ability to sum up values to an epic (specifically story points from child stories, bugs and tasks). There's a possible workaround mentioned in this discussion, but everything seems geared towards Automation For Jira Cloud. Is there anything currently possible for the Server version? Thx.

[Bill Sheboy]

Hi @Sherry Goyal 

I am trying to understand the example you posted on accumulating a field in an epic from its children.  Where can I find documentation on {{fieldChange.to}} and {{fieldChange.from}} as I do not see those on the Atlassian smart value pages I have found with searches?  Thanks!

Best regards,

Bill

====

** Please disregard; I found it. 

Of note, the technique using fieldChange may not be reliable as this captures the last field changed, and possibly others. When multiple fields changed and the event trigger is fired, the value in fieldChange may be a list. There does not appear to be a way to detect which field was changed using information only in fieldChange.  Hopefully the fields supported by changelog will be increased, eliminating this issue.

__Bill

[Sofia Quintero]

@Maria Yacoub have you tried the workaround for epic that Sherry Goyal showed? 

[Sofia Quintero]

Hello @Sherry Goyal  

I´ve tried to replay the workaround example that you gave before, regarding how to sum the original estimate field from epic´s child issue. But it didn´t worked for me.
My doubt is about how you write the smart value, in the secreen shoot looks different from over, wich is the correct? or both are valid?

{{#=}}({{fieldChange.to}} - {{fieldChange.from}} + {{issue.original estimate}})/60{{/}}

{{#=}}({{fieldChange.to}}/60 - {{fieldChange.from}}/60 + {{issue.original estimate}}){{/}}

[Sherry Goyal]

@Bill Sheboy 

https://support.atlassian.com/jira-software-cloud/docs/smart-values-general/ - look for {{fieldChange}}.

@Sofia Quintero 

Please use either

{{#=}}({{fieldChange.to}} - {{fieldChange.from}} + {{issue.original estimate}})/60{{/}}

OR

{{#=}}({{fieldChange.to}}/60 - {{fieldChange.from}}/60 + {{issue.original estimate}}/60){{/}}

**Please note "/60" was missing in 3rd field.

@david catriel For server, there is feature request to provide Smart values (Sum, average, max, min, aggregate).  Maybe you can vote it.

[anthony_butler]

Hi @Sherry Goyal , I don't suppose you've the chance to look at my question about this have you? 

[Bill Sheboy]

Thanks @Sherry Goyal  -- I believe that the documentation link you sent confirms what I noted: fieldChange can contain multiple field changes and so may not be reliable for this method as the specific field changed (in the list of changes) cannot be identified.  If I missed something in how fieldChange works, please let me know.

Thanks again,

Bill

[david catriel]

Thx for the feedback, @Sherry Goyal, but seeing that Jira Server is now nearing its end (sales ending Feb 2021 and product support ending Feb 2024 - https://www.atlassian.com/blog/announcements/journey-to-cloud), I don't think any of these feature requests will be making it in (and they should probably all get closed anyway so anyone waiting for them doesn't get their hopes up). Will look for solutions via plugins instead.

[Kevin Brung]

Hi @Sherry Goyal 

Here's my rule, it doesn't work and I don't know why.

I try to sum Original Estimate of Sub-Tasks into parent Task.

It's never triggered when I modify the Original Estimate field on a subtask.

Could you please help me?

EDIT : found a solution on my own by using a custom field instead of the Original Estimate field.

[Meital Adir]

Hi all, 

I'm trying the same rule based on discussion here, for Epic to sum up its issues (without sub tasks),

I have custom text field on the epic, and also tried to use Original estimate field on the epic. 

I've used: 

{{#=}}{{issue.Original estimate.sum}} / 60{{/}}

 (default time tracking is days)

it doesn't work.

can someone assist please?

Thanks

[Ahmet Kilic]

Hi there,

{{#=}}({{fieldChange.to}}/60 - {{fieldChange.from}}/60 + {{issue.original estimate}}/60){{/}}

not working in cloud

[Meital Adir]

Thanks for you reply. we're using cloud.

[Santiago]

Hi @Sherry Goyal first of all thanks for sharing this!!

We have implemented a rule to update both original and remaining estimates of parent issues whenever those values are updated on any child issue. 

We have it setup with two separate actions using advanced editing with smart values:

One for original estimate : 

{
"fields": {
"timetracking": {
"originalEstimate": {{#=}}{{#=}}{{subtasks.timetracking.originalEstimateSeconds.join(" + ")}}{{/}}/3600{{/}}
}
}
}

And one for remaining estimate:

{
"fields": {
"timetracking": {
"remainingEstimate": {{#=}}{{#=}}{{subtasks.timetracking.remainingEstimateSeconds.join(" + ")}}{{/}}/3600{{/}}
}
}
}

The problem we are facing is that for both actions Automation is updating the Original estimate field. We added comments to the rule to make sure the values were being calculated correctly and were able to confirm that:

but cannot figure out why both steps for the rule update the original estimate field:

We have already tried separating it into two rules but we are still having the same behaviour. Any ideas will be appreciated.

Thanks in advance!!

Santiago

[Ahmet Kilic]

Hey Santiago,

change the trigger to Work Logged, and then it is working only Task-Subtasks, but not Epic.

Best,

Ahmet

[Ouwaïs CHAOUI]

Hello folks,

Well I tried to create the same rule as described in this article to update my US original estimations when I create a new subtask.

The problem is that the rule does not work. I have in my logs this error :

 

It looks like when I create a subtask from the US windows, it does not recognize the parent.

How did you make it work in your example ? (I used the same rule as you).

Regards,