How rollups are computed

The one principle

Every subtree collects the list of values of all estimated issues inside it — the row’s own value (if set) plus every descendant’s, at any depth. Issues without a value are simply absent from that list: they are not zeros, and they never drag an average down. The operation is then applied to the list:

Operation	Meaning
sum	Total of the list
avg	Sum ÷ number of estimated issues
median	Middle of the sorted list (even count → mean of the two middles)
min / max	Smallest / largest estimate in the subtree
count	Number of issues in the subtree — estimation ignored

A leaf with value v therefore shows v under every operation except count; a leaf without a value shows — (a dash, never a fake zero).

Unestimated

N unest. counts leaf issues without a value. Parent containers without their own estimate are the Jira norm, not a data-quality problem, so they are not counted — the badge highlights actual work nobody sized.

Dirty hierarchies, honestly

Real Jira data is messy, and the app surfaces it instead of guessing:

• Cross-project children whose parents are outside your selected projects are grouped under “No parent in view” in their project — with correct aggregates, one click away.
• Issues without values, when they are flat rows with no children, are grouped under “No value set” — nothing is ever silently hidden.
• Cycles (from botched imports) are broken deterministically and reported in the footer, so no subtree is ever double-counted.

Per-project rows

With multiple projects, each project row is computed like any other subtree — meaning its median and average come from the full distribution of that project’s values, not from combining epic-level results (which would be mathematically wrong). Its count is the number of issues in the project.