Your Story Says 13 Points. Its Subtasks Say 10. Here's How to Catch That Automatically.

Every backlog grooming session hits the same wall. Someone points at a story, breaks it into subtasks, estimates each one — and a sprint later nobody can say whether the story's original estimate still means anything. The number on the parent and the sum of the work underneath have quietly drifted apart, and nothing in Jira will ever flag it.

That's not sloppiness. It's a gap in the product. Jira does not roll up numbers. A parent's Story Points and the sum of its subtasks' Story Points are two unrelated fields that diverge the moment the breakdown changes, and Jira will never reconcile them for you.

The workarounds all leak

Ask how to sum a field across an issue's subtasks and you'll get two answers.

The first is Automation rules — Atlassian's own knowledge base walks you through a rule with lookupIssues and a smart value like {{lookupIssues.Story Points.sum}}. It works, until it doesn't: the rule fires on some events and not others, it has to be cloned per project and per field, and when it silently stops, the stale number it last wrote looks exactly like a live one. A wrong number that looks right is worse than no number.

The second is buying a dedicated rollup app. Fine tools, one more line on the bill, and most of them park the result somewhere that isn't a plain, searchable Jira field.

The fix: a field that does math

Argon ships a Calculated Field — a custom field type whose value is a mathematical expression over the numeric fields on an issue, its subtasks, or both:

That's a live rollup of every subtask's Story Points onto the parent — recursive through nested subtasks, recalculated automatically, with no Automation rule to babysit. Expressions can use + - * /, brackets, and the functions sum, avg, min, max, and p50 across three scopes: issue: (this issue's own field), children: (its subtasks, recursively), and issueandchildren: (both).

One honest note the screenshot makes plain: the editor works in field IDs, not names — here customfield_10072 is the Story Points field, and the right-hand panel lists every ID you can reference. Set it up once in Jira Settings → Custom fields, pick your expression, add the field to a screen. Done. (Step by step: how to create a calculated field in Jira.)

The part nobody else does: query it

Because the result is a real number field, native JQL can search it. That turns a display convenience into a data-quality tool.

Find parents whose subtasks carry no estimate at all:

Those are the items sitting on your board with a rolled-up size of “shrug” — broken down, but never actually sized.

Catch estimate drift. Add a second calculated field — call it Estimate Drift:

Now the gap between what the parent claims and what its subtasks actually add up to is a number on every issue — here a story estimated at 13 whose three subtasks sum to 10.

And because it's searchable, a single query finds every parent whose breakdown no longer matches its headline estimate:

Run it as a saved filter, drop it on a dashboard, or wire it into a board quick-filter. Your data-quality check becomes a query instead of a quarterly cleanup.

Spot the work that outgrew its level

p50 gives you the median — a statistic Jira has never offered out of the box:

A parent whose median subtask is 13 points isn't a task with big subtasks; it's a task that should have been a story.

Statistics without the export

The same mechanism answers the “quick stats” questions that usually end in a CSV export: the average subtask size under a parent (avg(children:customfield_10072)), the single biggest estimate anywhere beneath it (max(issueandchildren:customfield_10072)), or blended expressions that weigh a rollup against another field. If it's a number on an issue or its subtasks, you can aggregate it — and then search on the aggregate.

One rule the editor quietly enforces: the math operators apply to issue: fields and function results, not to a children: scope directly — so issue:a - sum(children:b) is valid, and the Estimate Drift field above follows exactly that shape.

Forge-native, as always

Like everything we build, Calculated Field runs entirely on Atlassian Forge. The math happens inside Atlassian's own infrastructure; no external server ever sees your field values. Why that matters.

Try it

Calculated Field is part of Argon on the Atlassian Marketplace — the same app that gives you transitionedBy, regex search, and 30+ other JQL functions. Install it, create one rollup field, and find out what your subtasks have been hiding.

Get Argon on the Atlassian Marketplace →