Jira issue hierarchy explained: how totals should roll up

If you have ever looked at a Jira project and wondered how epics, stories, and subtasks are supposed to relate — and why getting a simple total out of them is so hard — this page is the missing manual.

The hierarchy, level by level

Jira nests work in parent–child layers:

Level	What it is	Typical estimate?
Epic (and levels above)	A large goal spanning weeks or months	Usually no — it’s a container
Story / Task / Bug	A concrete, deliverable piece of work	Yes — this is where story points live
Subtask	A step inside one piece of work	Sometimes

Two details people miss:

• Children can live in a different project. A platform epic can have stories in three teams’ projects. Jira allows it; most reporting tools quietly ignore it.
• Containers usually carry no estimate of their own — and that is fine. An epic without points is a folder, not a data-quality problem.

What “rollup” actually means

A rollup walks the tree bottom-up: each level shows the total of everything underneath it.

Simple for sums. But the moment you want anything beyond a sum, the honest math gets specific — and this is where many tools cut corners:

Averages. The average should divide by the number of estimated issues, not all issues. If 3 of 10 issues have points, the average of those 3 is the truth; dividing by 10 pretends the other 7 are zeros.

Medians. The median of a group must come from the full list of values in that group. You cannot compute a “median of medians” — combining per-epic medians gives a statistically wrong number. A correct tool carries the whole distribution up the tree.

Unestimated work. Issues without points are not zeros — they are unknowns. A trustworthy rollup counts them separately (“6 unestimated”) and shows you exactly which issues they are, so before sprint planning you can click straight to the work nobody has sized.

Messy reality. Real instances contain issues whose parents were deleted, children of epics from other projects, even circular links left by old imports. A tool that silently drops or double-counts these produces confident nonsense. The honest options are: show them in a clearly labeled group, and say so in a diagnostics line.

Why this is hard to do fast

A real rollup across projects means reading every issue in the tree — easily tens of thousands — then computing the whole hierarchy. Doing that at the moment you open a dashboard is why so many reporting gadgets crawl on large instances: Jira gives apps a hard 25-second budget per render, and portfolios outgrow it.

The alternative is to compute before you arrive: keep a synced snapshot inside Jira, refresh it in the background, and let the dashboard read a prepared result. That approach is what our gadget, Hierarchy Totals, is built on — the freshness & performance doc explains the mechanics in user terms, including exactly when data refreshes and how the gadget tells you how fresh it is.