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: * How can I implement Sub-task → Story → Epic time rollup * Is there any automation I can perform

Hey @Shivoy Malhotra , I see, in the current version of JXL, it would be possible to roll the values up (to any level) via a custom formula column. E.g. a `JFL script` like the one below would give you the sum of the originial estimates on any level in hours. const walk = (item: WorkItem): number => { return SUM( item.originalEstimate ?? 0, ...item.hierarchy.children.map(walk) ); } const summedUpOriginalEsitmates = walk(this); // original estimates are stored as seconds in jira, so we want to convert it to hours return summedUpOriginalEsitmates / 3600; This works, but I would only consider this as an intermediate workaround. Good news though is, that we are currently in the process of adding another option to our structure levels - `Hierarchy and sum-up`, which will allow you to roll-up also these values in your hierarchy definition, without any intermediate sum-up row. Once shipped, it will look like this: In the screenshot above, you see the `original estimate` and `time spent` values rolled up, the roll up style will be configurable as well, among other things. I cannot give an exact ETA, but I'd expect it to be shipped soon-ish 🤞. Cheers, Paul

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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:

How can I implement Sub-task → Story → Epic time rollup
Is there any automation I can perform

Accepted answers

All comments

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.

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

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.

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

Epic Hierarchy.png

Paul Glantschnig _Appfire_

Hello @Shivoy Malhotra,

your observation is correct, and @Trudy P Claspill has covered the native picture well: Jira's Σ fields aggregate exactly one level, and automation-based rollups work but come with the cascading-update problems she described.

To add one more option to the app suggestions in this thread: this multi-level rollup is a core use case of JXL for Jira, the app my team and I work on.

JXL is a full spreadsheet/table view of your work items. You can define a custom structure matching your exact hierarchy (Milestone → Epic → Story → Sub-task, including levels above epic from your Plans hierarchy configuration), and enable sum-ups on any column. Original Estimate and Time Spent are then totaled at every level, all the way up, computed live from the underlying work items, so there are no automation rules to maintain and no double-counting questions:

Sum-ups through a custom hierarchy in JXL

For your rolled-up progress percentage, a formula column can compute Time Spent ÷ Original Estimate from the aggregated values, and conditional formatting can color epics that run over.

Any questions, just let me know.

Best, Paul

Shivoy Malhotra

Hello Paul, Thank you for the response. I have a few questions here on the product. I would like to confirm:

if i log time in hours at sub task level will it roll up at epic level. Assuming our structure remains the same: Epic -> Story -> Sub task
Any limitations around hierarchy depth and double-counting scenarios
If estimates exist at multiple hierarchy levels, does JXL sum all values as-is or provide controls to avoid double counting?

Shivoy Malhotra

Hello Paul, I observed I am using JXL Sheet where i am facing this issue. if i log hours at a sub task level the progress or work ratio doesnt roll up at epic level.

Paul Glantschnig _Appfire_

Hey @Shivoy Malhotra , sorry for missing your reply, let me check...

Josh

You're right about the native picture: Jira's Σ / aggregate time fields only go one level (Sub-task → Story). They do not cascade Story → Epic, so Epic Time Spent and Original Estimate stay understated when worklogs live on Sub-tasks.

Native options: (1) Put Original Estimate only on leaf work. (2) Automation that recalculates a custom number field on the Epic from a fresh sum of children on worklog create/update/delete (overwrite, don't increment). (3) Plans/timeline views are visual and do not rewrite Time Spent on the Epic.

Disclosure: I work on Aneto Hours Reports and Aneto WBS on the Marketplace — useful for multi-level hour rollups without writing Time Spent back onto Epics. https://marketplace.atlassian.com/apps/1219348/aneto-hours-reports-and-resource-planner

Are you trying to see Epic totals for reporting, or do you need the native Time Spent fields on the Epic for filters/SLAs?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud