How the numbers are calculated

Sumline adds up four fields from the bottom of the issue hierarchy to the top: subtasks, the stories, tasks, bugs and requests above them, epics and, on Jira Premium, which adds the level above epic, initiatives. Children that live in another space are counted under their parent too.

The four fields

Story points, shown as done / total.
Original estimate: what was planned. Its done / total shows how much of the plan sits on finished issues.
Time spent: what was logged, ever, so it only goes up. It is added up at every level, whatever else is estimated.
Remaining estimate: what Jira currently thinks is left. It goes down as work is logged, but people also re-estimate it by hand, so it is not original minus spent.

Sumline never works one of these out from another. Times are shown in hours and minutes. An admin can leave any field out; see Settings.

What counts as done

Any issue whose status is in Jira’s Done status category. Status names are never used, so renamed or custom statuses such as “Shipped” count as done as long as they sit in that category.

Each estimate counted once

When a parent and its children both carry an estimate, Sumline counts one level, never both. A story estimated at 8 whose subtasks also add up to 8 counts as 8, not 16.

By default the children win and the parent’s own value is set aside. An admin can choose “parent wins” instead, which sets the children’s values aside. Either way nothing disappears silently: the Sumline panel names each value it did not count, with its issue and field, the tables mark the row “mixed estimates”, and the CSV lists the issues in its Exclusion note column. Time spent is not affected: logged time is always added.

Issues with no estimate

An issue with no value in any rolled-up field adds nothing to the estimate totals, and it is never counted as 0. Sumline names it instead:

the panel’s “Check the estimates” box lists the unestimated issues, and its child table marks such a child “No estimate”, or “N unestimated” when only some of the child’s own subtasks are estimated;
the Details column shows “Unestimated children” with their keys (the first five, then a count);
the tables and the gadget show “N unestimated” in the Warnings column.

An issue whose parent’s estimate is the one counted is covered by it, so it is not called unestimated. Time logged on an unestimated issue still adds to Time spent.

% complete

Always two numbers, side by side:

By estimate: story points done ÷ story points total. When no story points are counted, time is used instead: time spent ÷ (time spent + remaining estimate).
By issue count: done issues ÷ all issues, across every level below the parent.

A parent with nothing estimated below it shows “—” with no bar, never 100 %. On the tables, “% complete by” chooses the basis for every row: Auto (story points, else time), Story points, Original estimate, or Time (spent ÷ spent + remaining).

The rows of a table

A table has one row per epic, and per initiative where your site has that level, so an epic appears as its own row and again inside its initiative’s row. That is why the gadget shows no grand total: the rows overlap. An admin can limit the rows to initiatives; see Settings.

The Status filter matches the row’s own status category and the Assignee filter the row’s own assignee. The Sprint filter, “Sprint (any issue in the epic)”, keeps a row when any issue in it is in the chosen sprint; “Backlog (no issue in a sprint)” keeps the rows with none. The Sprint filter is greyed out in a space where no issue is in a sprint, such as a service desk.

The size limit

A table, the Sumline tab, Sumline under Apps or the gadget, rolls up at most 2,000 issues, and the count is the whole rolled-up tree: every issue in the selected spaces plus every child of their epics that lives in another space. A space with 300 issues whose epics hold 1,800 stories elsewhere is a 2,100-issue tree and is over the limit.

Above it Sumline stops and says so, “Too large for the rollup table”, rather than showing a partial number. Choose fewer spaces, or open the Sumline panel on an epic: the panel has no issue limit.

How fresh the numbers are

Sumline computes a rollup when you open a view and keeps it for five minutes, per person; the next open in that time reuses it, and a very large table is recomputed on every open instead. Every view says how old its numbers are (“Updated just now”, “Updated 3 min ago”) and has a Refresh button that recomputes them straight away. When an admin saves the settings, every rollup is recomputed on its next open.