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; } } }

Does original estimate aggregate from subtasks to parent story in team-managed projects?

Anna Laptyuhova

Hi community,

I'm working in a team-managed Jira Software project with time estimation enabled (original estimate in hours).

Our current setup:

Stories in the backlog
Each story is broken into subtasks (Back / Front / QA)
Original estimate is set on each subtask in hours

Expected behavior:
The sum of subtask estimates automatically rolls up and displays on the parent story.

Actual behavior:
The parent story shows no estimate — subtask values don't aggregate to the parent.

What I've already checked:

Time estimation is enabled in Space Settings → Features
Original estimate field is added to all work types including subtasks
This is a team-managed project (not company-managed)

My question:
Is subtask-to-parent estimate aggregation supported in team-managed projects? If not, is there a recommended workaround that doesn't result in double-counting in reports (burndown, velocity)?

Accepted answers

Germán Morales

Hi @Anna Laptyuhova , short answer: no. Subtask original estimates don't roll up to the parent in team-managed projects, and your configuration isn't the problem. That aggregate, the Σ that adds subtasks onto the parent, exists only in company-managed projects, and even there it is just a display in the time-tracking panel, not a value Jira writes into the story's Original Estimate field. Team-managed time tracking is the slimmer version and doesn't surface that roll-up at all, which is why your story stays blank.

The clean way to get a real total without double-counting is an automation rule: on a subtask created, edited or deleted, recalculate the sum of the subtasks' original estimates and write it to a separate number field on the story, say Subtask estimate total, while leaving the story's own Original Estimate empty. Keeping it in its own field is what avoids the double count, since your board's velocity and burndown read the estimation statistic you set at the story level, story points or time, and never pull from subtasks, so the two don't collide. Others have wired up exactly this, for example summing subtask estimates onto the parent with automation.

All comments

Germán Morales

Rahul_RVS

Hi @Anna Laptyuhova

For rolling up time tracking values to parent, if you are open to try out a mktplace app, take a look at,

Agile Tools

The app allows you to view your issues in a hierarchy list view with roll up of time tracking data at Epic level and at each parent level.

The hierarchy works for issue links as well with the Links Hierarchy module of the app. All the app features can be added as gadgets to a dashboard.

Do give it a try.

Disclaimer : I am one of the app team member

Epic Hierarchy.png

Fatma Uzundemir from The Starware

Hi @Anna Laptyuhova

This is expected behavior in team-managed Jira Software projects. Jira does not natively roll up Original Estimate values from subtasks to the parent issue, so the Story will not automatically display the total estimate.

If your goal is to keep estimates only on subtasks and automatically calculate the total value on the parent issue, you can use a calculated custom field solution like Sum Up Field.

Sum Up Field allows you to aggregate values from child issues and display the calculated result on the parent issue. You can select the field you want to calculate (for example Original Estimate, Story Points, or any numeric custom field) and choose the calculation method:

SUM → Total of all child values
AVERAGE → Average value of child issues
MIN → Lowest value among child issues
MAX → Highest value among child issues

🌱EXAMPLE:

Story
├── Backend Subtask → 5h
├── Frontend Subtask → 8h
└── QA Subtask → 3h

Using Sum Up Field (Original Estimate + SUM):

✔️ Story displays: 16h

The value is dynamically calculated, so any change in subtask estimates is automatically reflected on the parent issue.

This also avoids maintaining estimates in two places (parent + subtasks), helping prevent duplicated effort calculations and keeping reports like burndown and velocity more consistent.

Sum Up Field can be used not only for estimation scenarios but also for different Jira numeric fields and custom fields where you need automatic roll-up calculations across your issue hierarchy.

🍀 To learn more, feel free to contact me or explore the application through the Atlassian Marketplace link I’ve provided. 🍀
Disclaimer: I work for the vendor who developed this application.

Hempel

Hi @Anna Laptyuhova — the other answers here have the Jira side right. Original estimates don't aggregate in team-managed projects. That's just a native limitation, and the automation workaround is genuinely a reasonable band-aid.

One distinction worth making: if what you're actually after is visibility into time spent across a hierarchy (subtask → story → epic), that's a different problem than the estimate field itself.
A couple of tools handle this differently. Tempo Timesheets rolls up logged time from subtasks to the parent story and epic — but it shows up in Tempo Reports, not written back to the Jira estimate field. That's actually intentional: it keeps estimates and actuals cleanly separated so you don't end up with the double-counting problem mentioned above. Structure by Tempo also supports hierarchy-level aggregation if your team is managing work across a portfolio view.

Neither approach writes to Jira's native estimate field — but if the goal is reporting on time by hierarchy level, that's where these tools tend to do the heavy lifting.

Happy to share more about how the reporting layer works if that's useful.

(Disclosure: I'm on the Tempo team.)

Danylo Iliukha _Appfire_

Hi @Anna Laptyuhova
|

To the best of my knowledge, team-managed projects do not roll up Original Estimate from child work items to the parent story. Your setup sounds correct; this is a platform limitation, not a configuration gap on your side.

In company-managed projects, Jira can show a Σ total of subtask estimates in the time-tracking panel on the parent, but that is display-only. Jira does not write that total into the parent's Original Estimate field. Team-managed time tracking is slimmer and does not surface even that Σ roll-up, which is why your story rows stay empty.

For reporting, velocity and burndown on a Scrum board read the estimation statistic configured at the board level (story points or time) from issues included in the sprint. Subtasks are usually excluded from those charts when estimation lives on the story. That is helpful here: you can keep estimates only on subtasks without the board double-counting them, as long as the story's own Original Estimate stays empty.

If you need a stored total on the parent, the common native workaround is a global automation rule:

1. Trigger: Field value changed on a child work item (Original estimate), plus issue created/deleted on child work items so totals refresh when subtasks are added or removed.

2. Lookup issues: JQL `parent = {{issue.parent.key}}`

3. Edit issue on the parent story: write the sum to a separate number field (for example "Subtask estimate total") using `{{lookupIssues.timetracking.originalEstimateSeconds.sum|0}}`, converted to hours if needed.

Keeping the rollup in its own field avoids colliding with the story's native Original Estimate and keeps burndown/velocity cleaner. If you specifically need the parent's Original Estimate field populated for backlog visibility, automation can target `timetracking.originalEstimate` on the parent instead, but test carefully in your space since team-managed field handling can be picky.

Hope that helps,

Danylo

Danylo Iliukha _Appfire_

One more angle on the rollup question, @Anna Laptyuhova : if the main goal is seeing each story's total estimate (Back + Front + QA) without maintaining automation, there is a reporting-first option that sidesteps the native gap.

If you're open to an app from the Atlassian Marketplace, JXL for Jira is a spreadsheet-style view where you open your backlog as a parent/child hierarchy and turn on a sum-up on the Original Estimate column. Each story row then shows the combined estimate of its subtasks automatically, and it updates whenever a child estimate changes.

JXL does not write that total back into the story's Jira Original Estimate field, so the native backlog will still look blank unless you use automation. But for planning and review (and avoiding double-counting in reports while keeping estimates on subtasks), a saved JXL sheet can be a practical substitute.

I'm on the JXL team.

Best regards,

Danylo

Xenia Chilkowich

I just posted a similar question. It is ridiculous that this is not available in team managed projects. I spent hours creating automations and a custom field to solve for this. I see others have too and even installed apps. Atlassian if you are listening, you need to provide this feature for team managed projects. Why do you have so many limitations on critical features for team managed projects? Many of us are in this environment and cannot enjoy the ability to customize that comes with this because you cripple us with all of the limitations that can only be solved by going to company managed projects. Do better please!

Josh

You are not missing a setting. Team-managed Cloud does not roll Original Estimate from subtasks onto the parent story.

In company-managed projects, Σ Original Estimate can show in the time-tracking panel. That is display-only. Jira does not write the total into the parent’s Original Estimate field. Team-managed time tracking is slimmer and does not surface even that Σ.

If you keep estimates on subtasks and leave the story’s Original Estimate empty, burndown and velocity will not double-count, because those charts read the board’s estimation statistic at story level. If you need a stored total on the parent, a separate number field plus automation is the native workaround. If the goal is seeing original / spent / remaining hours on every parent without writing those totals back into Jira estimate fields, that is a hierarchy view, not a field-copy rule.

Disclosure: I work on Aneto WBS.
Listing: https://marketplace.atlassian.com/apps/1219682/wbs-work-breakdown-structure

Daria Spizheva_Reliex_

Hi Anna!

Subtask-to-parent estimate rollup isn't supported in team-managed projects. In company-managed projects the time tracking panel has an "include subtasks" view, but team-managed projects simply don't aggregate estimates up the hierarchy. For workarounds without double-counting:

Keep estimates on subtasks only and leave stories unestimated. Burndown and velocity in team-managed projects work off story-level values, so this avoids counting the same hours twice — the trade-off is your backlog view won't show story totals.
Automation rollup — a rule that sums subtask estimates into the parent's Original estimate on change. It works, but be careful: now the hours exist on both levels, and time-based reports may double-count. If you go this route, put the rolled-up number in a custom field instead of the real estimate field.
Consider moving that project to company-managed if rollups matter a lot — honestly the cleanest native fix, though migration is its own project.

And a note from our side — I'm from the ActivityTimeline team. If the underlying need is "see the real total effort per story and per person," our app reads the estimates from Jira and does the aggregation for you: the issues panel shows the Epic → Story → Subtask hierarchy with summed remaining estimates per group, and workload is calculated from wherever the hours actually sit, without double-counting. Might be worth a look if reports are the end goal — there's a 30-day trial.

Hope this saves you some digging!

Знімок екрана 2026-09-04 о 10.26.45.png

Xenia Chilkowich

Danylo Iliukha _Appfire_This is what I ended up doing. I had to make modifications to also ensure it adjusts for changes to the children that would require an update to this field. The challenge I'm running into now is that I am exceeding my worfklow limits

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-software

jira-cloud