Community
Q&A
Jira
Questions
Does original estimate aggregate from subtasks to parent story in team-managed projects?

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

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)?

5 answers

1 accepted

4 votes

Answer accepted

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.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

1 vote

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.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

1 vote

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

0 votes

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

0 votes

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.)

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

A pop-up survey could appear while you're here --curious what it's for? Click here to learn more!

Forums

Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

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

5 answers

1 accepted

Suggest an answer

Was this helpful?

Thanks!

DEPLOYMENT TYPE

PRODUCT PLAN

TAGS

Community showcase

Atlassian Community Events