Sum Up Original Estimations - Jira Automation

[dennis.weinberger]

So I currently had to build a lot of workarounds to get the sum of all original estimations into the Epic. But it can lead to errors, when I clone a task and add it into another epic (it is an edge case, I know, but I still want to fix this :D) Is there an easy way of doing this?

Something like:

"{{#=}}{{lookupIssues.original estimate.sum}} / 60{{/}}"

or

"{{#=}}{{issue.subtasks.Original Estimate.sum}} / 60{{/}}"

for Epics too? 

It is working for stories with sub-tasks, but not for Epics. 

Best Regards

Dennis

[uttam kumar bhatta]

Is it giving correct value for original estimates?

I tried to use the same logic, though the rule is triggering - it is not returning correct value. Example - In a story I have created 2 tasks, task 1 has Original estimate 2d 3h & task 2 has Original estimate 7h, so for story Original estimate should display as 3d 2h, however it is showing me a weird number like 45w or in week all the time for any hour estimation also. Can anyone point the mistakes?

[Mykenna Cepek]

Hi Dennis. Sorry to disappoint, but the short answer for you is this: you'll need to pay for a Jira add-on to do this.

The basic set of JQL and Automation features in Jira (even for the Premium plan you have) do not support the aggregation of data from Stories to Epics in arbitrary ways.

As you've discovered, there is some support from Sub-tasks to Stories. So it seems like it would follow that you could sum things up from Stories to Epics. Again, short answer: nope.

I wrote this rant last month about why automation in Jira is incapable of currently doing this. Many of us have tried to make this work, and failed.

There is a link to a related bug/suggestion in my rant, and you can vote for that to get fixed.

The only other approach I know is to explore the Atlassian Marketplace for an add-on to Jira that you can afford that will enhance your queries and operations on the results. That can get you to computing the result you need. But I don't have enough experience with them -- particularly how to use them within automation -- to help further. The instances I manage include minimal add-ons.

If you find a solution that does work for you, please share it here for others! Best wishes.

[dennis.weinberger]

Hey Mykenna Cepek,

then I need to go with my workaround. It is almost possible, when you use the values fieldChange.from and fieldChange.to depending on the Trigger Time-tracking (it's called Zeiterfassung in german, I can't really say how they translated it :D ).

With a lot of if and else-if I almost got it. I can show you my Automation if you want to. Maybe we can work together on some workarounds :).

But yeah, it would be cool to have something like for tasks and subtasks. Because the workround is error prone

Best Regards, 

Dennis

[Ihar Kanunnikau]

Dear @Mykenna Cepek 

Thank you for such a detailed explaination of the problem. Could you please clarify some plugins/add-ons that can help to solve this problem?

Thanks

Ihar

[Mykenna Cepek]

Unfortunately, I have not researched Jira apps to solve this problem.

Hopefully others who have needed to address this in their instances can suggest some apps that they have found helpful.

We're currently using Tempo Timesheets to provide a solid aggregation of logged time at various levels (including Epics, but also with Accounts and Customers which are layered onto Jira by Tempo). We don't use the "timesheets" aspect of Tempo at all, but we make heavy use of the logged time reporting features which support our critical client-billing processes. This is a paid app (not cheap), but it's solid, and the time logging features (ease of entry, visibility of logged time, different views and reports, even a Chrome plug-in) really help support our time tracking needs.

[Iryna P.]

@dennis.weinberger could you show me your automation if possible? I'm struggling to sum up estimates from stories into epics and can't get any meaningful results(((