Epics Tab — Feature Guide

What it's for

The Epics tab shows the project's hierarchical scope — every epic plus its child issues — and rolls up progress, scope-change, and status per epic. Where the Sprints tab is organised around time (which iteration owns which work) and the Scope tab around change over time, the Epics tab is organised around grouping (what work belongs together) and completion against that grouping.

It answers four questions: what are we building right now; how far through each epic are we; which epics are growing in scope versus shrinking; and which epics are at risk of missing their target. It is intended for product, programme, and delivery leads who want to assess the project at the work-package level without opening Jira.

The tab requires that issues are linked to a parent epic in Jira. Issues without an epic parent are excluded.

Toolbar

A single row at the top with the search input, the status filter, and the assignee filter. All three filters compose — an epic must match all of them to appear.

Search field

A text input that filters the epic list as the user types. Matching is case-insensitive and runs against the epic's summary and Jira key. Empty input shows everything.

Status filter

A dropdown labelled All Epics. The options are All Epics plus every status string that appears in the current set of epics — typically a mix of Done, On Track, At Risk, Behind, Overdue, To Do. The status values are derived (see Status derivation below), not pulled directly from Jira's workflow.

Owner filter

A dropdown labelled All Owners. Lists every assignee found across the visible epics; selecting one narrows the list to that person's epics only.

Section header

Collapse All button

Appears only when at least one epic is currently expanded. Clicking it closes every open epic in one click. There is no symmetric Expand All button — expanding is one-at-a-time by clicking individual rows.

Epic row (always visible)

The Epics tab is presented as a flat list of epic rows, each clickable to expand a child-issue table beneath it.

Epic row columns

• Caret — a right-pointing chevron when the epic is collapsed, down-pointing when expanded.
• Epic — the issue summary in regular weight; the Jira key beneath it as a small link. Clicking the key opens the epic in the Project Commander side panel; Ctrl/Cmd-click opens the issue in Jira in a new tab.
• Assignee — an avatar chip with deterministic initials (AC, BS) and the colour from the shared name-hash palette, plus the assignee's name. Unassigned epics show —.
• Progress — a horizontal bar (6px tall) plus a percentage label. The bar fills from left to right and is coloured by progress band: green ≥ 60%, amber 30–59%, red < 30%. The percentage is capped at 99% when work is mathematically complete but the epic itself is still marked open in Jira (so the row never reads 100% on an in-progress epic).
• Points / Hours — X of Y pts (or of Y hrs). The unit and the calculation depend on the project's estimation mode (see below).
• Start Date — the epic's created date, shown short (Apr 12) or with year (Apr 12, 25) when the year differs from today.
• Due Date — the epic's dueDate. Same formatting as Start Date. — when missing.
• Status — a coloured pill (see Status derivation below).
• Scope Change — a signed percentage change versus a baseline date (see Scope change below). Red for growth, green for shrink, grey — when no baseline can be established or the epic is done.

Hover and done styling

Hovering a row tints the background (#FAFBFC). Epics in Done status render at 60% opacity so the open epics stand out.

Sorting

Every column header is clickable. Clicking toggles between ascending and descending; the active column shows a ▲ or ▼ next to its label. Clicking a different column resets to the default direction for that column. Sorts are stable, so a tied secondary order is preserved between sorts.

Child-issues table (expanded view)

Clicking an epic row toggles a child table below it. Only one epic's children are open at a time — clicking a different epic's row collapses any other open epic.

Child table columns

• Issue — Jira key (monospace blue link) plus issue summary.
• Status — a small pill: green for done-set statuses, blue for In Progress, grey for everything else.
• Assignee — plain text only (no avatar in the child table); — when unassigned.
• Points / Hours — X pts or X hrs per single issue.
• Sprint (sprint mode only) — the sprint name the issue currently lives in, or Backlog for unscheduled work.

Child table styling

Inset background #F4F5F7, 12px font, 32px left padding, no further nesting (subtasks under a story are not shown).

Status derivation

The pill in the Status column is computed, not read from Jira:

1. If the epic itself has a Jira status in the done set (done, closed, resolved, complete, completed) or progress hits the rounded 100% mark → Done (green).
2. Else if the epic has a due date and that date is before today and the epic is not done → Overdue (red).
3. Else if the epic has no children or progress is 0% with no in-progress child → To Do (grey).
4. Else by progress band: ≥ 60% → On Track (green); 30–59% → At Risk (amber); < 30% → Behind (red).

Scope change

A baseline date is the earliest active or future sprint start in the project. Issues created on or after that date count as added scope; issues that no longer exist (removed) reduce the original count. The percentage is (currentPts − originalPts) / originalPts × 100.

When the backend exposes a richer per-epic scope endpoint, that data is preferred; otherwise the client-side fallback runs over the issue list. The percentage is — (grey) when the epic is Done or when no baseline can be established (for example, no active or future sprints exist).

Empty / loading / error states

• Loading — while the JQL fetch is in flight and no cached issues are available, a centred Loading epic data… with a spinner.
• Error — if the fetch fails before any cached data exists, a red message Failed to load issues: <error>.
• No epics found — once the fetch completes but no issues with epic parents exist, the panel shows a large icon (📋), a No Epics Found heading, and a hint to ensure issues have epic parents in Jira.

Points vs. Hours mode

The whole panel respects the project's estimation mode.

• Points mode (default) — the column header reads Points, child rows read N pts, totals are integer or one-decimal points.
• Hours mode — header reads Hours, rows read N hrs. Calculations prefer Jira's remainingEstimate/originalEstimate/timeSpent (in seconds, divided by 3600) over story points; when none of those are present the app converts story points × hoursPerPoint (default 4) so totals still render.

In hours mode, done per issue is the time spent; total is the largest of original estimate, remaining + spent, and points-as-hours. Done equals total on issues marked done so the epic completion percentage matches the points-mode result.

Roll-up logic

The epic's Done and Total values are pure sums over its children, with the same point-or-hour rule applied to each child. Subtasks roll up into their parent story automatically through Jira's hierarchy — they do not appear as their own row in the child table.

Numbers are rounded to one decimal place to keep the column tidy.

Cross-cutting modes and settings

• Estimation mode (points / hours / days) — drives the column header, the unit suffix, and the formulas. Days mode uses hoursPerPoint × 8 per issue.
• Sprint mode on/off — toggles the Sprint column inside the child table. When sprints are off the column disappears.
• Demo mode / regression mode — swap the data source to built-in fixtures; the panel renders the same way.
• Programs (multi-project) view — when more than one project is active, the panel still renders one flat list; the parent app filters it to the currently-selected project.

How the numbers are computed

• Progress per epic — donePts ÷ totalPts × 100, with the 100% → 99% cap when the epic itself is not closed.
• Scope change — see ALGORITHMS Appendix → Scope Trajectory (rules) and the description above.
• Status pill — derived locally as documented in Status derivation (ALGORITHMS Appendix → Sorting and Visual Rules covers the colour bands).
• Velocity / forecast (no-sprint mode) — uses the team's rolling throughput over the configured sprintLengthWeeks window; described in ALGORITHMS section 4.

Effects on other parts of the app

• The Scope tab uses the same baseline definition for its scope reconstruction; a scope-change percentage shown here will match the Scope tab's per-bucket Added/Burned column.
• Sprint mode controls the visibility of the Sprint column here and the entire Sprints tab.
• Estimation mode is global; switching it from Settings changes the unit on every Epics row immediately.
• The status pill and the per-issue hover key are clickable; clicking opens the same in-app issue panel used by Sprints, Alerts, Risks, and Actions.