Unable to set up Sub-task to Epic time rollup

[Shivoy Malhotra]

Hi Atlassian Community,

I'm on Jira Software Cloud facing the following issue

My Setup:

• Hierarchy: Milestone -> Epic → Story → Sub-task 

Problem - Sub-task time doesn't roll up to Epic
Time logged on a Sub-task appears on the Story but never reaches the Epic. Jira's aggregate fields only go 1 level deep, making Epic-level progress inaccurate.

What I'm trying to achieve:

• Log time on a Sub-task → Story sees it → Epic sees it
• A custom Rolled-Up Progress % column at the Epic level showing true cumulative progress

What I have tried:

• Jira Plans — doesn't fix rollup

• Dashboard gadgets — same limitation

• Tried sum up filters for work ratio/ original estimate and original time logged.

Questions:

1. How can I implement Sub-task → Story → Epic time rollup 

2. Is there any automation I can perform

[Rahul_RVS]

Hi  @Shivoy Malhotra 

Welcome to the community !! 

There are multiple options to achieve this. Use automation rules or Jira Rest API's to create your own custom solution. Another workaround could be to try out a mktplace app. We have built one for the same use case.

Agile Tools

With this app you can easily generate reports such as:

- Sum up values to see overall progress for your Issue Hierarchy

- View the full hierarchy of linked issues, Portfolio/Advanced Roadmaps, Epics, and Subtasks.

- Track time spent by resources with multiple filters / category / grouping features

- All the app features can be added as dashboard gadgets as well

Disclaimer : I am one of the app team member

[Anton from JetHeads_io]

Hey Shivoy! 👋

Native Jira only rolls time up one level — a Sub-task into its direct parent, and that's where it stops. Nothing carries the hours further up through Story → Epic → Milestone, so the higher you look, the emptier it gets.

That full multi-level roll-up is exactly what JetTime (a third-party Jira app) does. It's a reporting layer over your existing Jira work logs — it reads the hours already logged and totals them at whatever level you pick, at any depth. And since Milestone sits above Epic as a custom level, JetTime picks that up too — so the hours reach all the way to Milestone, not just Epic.

• Every tier is its own grouping dimension — Story, Epic, Milestone, and anything above — a total at each, not just one
• All projects in a single report
• Custom fields and metrics roll up the same way — cost, billable hours, mileage, whatever you track
• Filter by user, date, or account; export to Excel or PDF

One more thing that fits your hierarchy directly, and it's something we haven't seen any other Jira time tracker do: you can turn logging off on the aggregation levels. Set the Log Work form by rule so people log only on real work — Sub-task and Story level — while Epic and Milestone stay pure aggregation. No one logs straight onto them, so nothing gets double-counted and the rolled-up totals stay clean.

One honest note on your first point: JetTime rolls the hours up inside its own reports — it doesn't rewrite Jira's Original Estimate field. Trudy's automation is the route if you need that native field populated; JetTime is the route if you just want to see the rolled-up time per level, without touching your data.

👉 JetTime on the Atlassian Marketplace

— Anton, JetTime founder

[Trudy P Claspill]

Hello @Shivoy Malhotra 

Welcome to the Atlassian community.

Besides logging time against sub-tasks, do you log time directly against Stories or Epics?

You could creation automation flow(s) that are triggered by the logging of time against a sub-task, and log that same amount of time against the Epic.

You said you want a custom Rolled Up Progress column at the Epic level. "Progress" implies that you can compare the actual time logged to a total amount of time you expect the work to take. How are you tracking the total amount of time needed to get the work done?

Creating a "custom' progress indicator is a completely separate topic. There is a field called Work Ratio. This is an out-of-the-box, calculated field that displays the percentage of your original time estimate that has been consumed by the time spent. You could create a filter for your Epics, create a dashboard with the Filter Results gadget that references your Epics filter, and include the Work Ratio field as a column to display in that gadget. That would show you the "progress" at the Epic level, but you would have to add to your Epics an Original Estimate that encompasses all the time you expect will be needed to complete the work.

[Shivoy Malhotra]

Thank you for welcome and quick response @Trudy P Claspill 

Currently my project structure is like below in sheets:

Project Structure: Epic → Story → Subtask

1. Original Estimate Does Not Sum Correctly at Epic Level

When I set original estimates at each level (e.g., Subtask = 1W, Story = 1W, Epic = 2W), I expect the Epic to display a total summed estimate of 4W (2W own + 1W Story + 1W Subtask). Instead, Jira only aggregates one level deep — it sums the Story's estimate (1W) with the Epic's own estimate (2W), giving 3W, and ignores the Subtask's estimate entirely. This means the Epic-level original estimate is always understated when subtasks carry their own estimates.

2. Hours Logged on Subtasks Do Not Roll Up to Story or Epic

When time is logged directly on a Subtask, it does not propagate upward to the parent Story or grandparent Epic. As a result:

• The Story's "Time Spent" field does not reflect hours logged on its child Subtasks
• The Epic's "Time Spent" field does not reflect hours logged on any Subtask beneath it
• This makes it impossible to track overall milestone progress based on actual hours worked, since the aggregate view at the Epic level is incomplete

3. Work Ratio Does Not Roll Up Across Hierarchy Levels

Jira's Work Ratio field calculates progress at the individual issue level only (Time Spent ÷ Original Estimate × 100). It does not aggregate or roll up across parent-child relationships. For example:

• Subtask 1: Work Ratio = 40%, Subtask 2: Work Ratio = 50%
• The parent Story shows no blended/aggregate Work Ratio for its subtasks
• The Epic similarly shows no aggregate Work Ratio across all nested Stories and Subtasks
• This makes it impossible to get a single, meaningful progress percentage at the Story or Epic level based on actual logged effort

All three issues stem from the same challenge i am facing I believe: aggregate time fields (Original Estimate, Time Spent, Work Ratio) only roll up one level deep — from child to direct parent - and do not cascade through the full Epic → Story → Subtask hierarchy. There is no native Jira Cloud feature that provides weighted or summed progress roll-up across all three levels based on logged hours.

[Trudy P Claspill]

Hello @Shivoy Malhotra 

You are correct in your description of what Jira does.

If you don't want to use a third party app, such as suggested by @Anton from JetHeads_io , then you option is to develop a work around.

One such work around would be to use Automation Flow(s) to take data from lower level(s) and add it to the higher level(s). There are distinct challenges with that, though.

- You don't know what information was added to the item directly versus rolled up to it.
- If the information at a lower level is changed, you have to cascade that to the higher levels, so you must understand if the change was an increase or a reduction.
- If changes are made on multiple lower level items at the same time, the automation to roll the changes up to the higher levels may not work properly depending on how the automation is structured.
- What if a lower level item is moved to a different parent? You then have to remove its rolled up data from the original parent and add it to the new parent.

I am usually an advocate for creating solutions with the native tools available, but in this case I recommend you look for an app to solve the problem. One like Anton suggested might work, or you might look for an app that offers Calculated fields that can sum up the data dynamically each time the work item is viewed.