User Guide

Jira's native child list is built for one Epic at a time. That is enough to open a ticket. It is not enough when a team is delivering several epics in the same project and needs a shared view of nested work, progress, and whether scope grew after a baseline.

HierarchyView treats the Jira project as the team. Open the HierarchyView tab on that project, add the epics that belong there, and the board remembers them. You do not pick a team inside the app. Use the numbers to see what is done, what was added after the snapshot, and what left an epic — not as a performance rating.

• Project tab (saved board) — in a Jira project, next to Board. This is the day-to-day view: add epics, expand children, switch Count / Pointed, and read the period snapshot. Search suggestions are scoped to that project.
• Apps → HierarchyView (lookup) — no project context. Lookup inspects any parent issue key on the site without saving it to a board. Use this when you need a one-off hierarchy, or when you are not already in a project.

Install and first-time setup live in Installation and Setup.

The Add epic field accepts a key, a summary search, or several keys pasted at once (comma, semicolon, or whitespace). Type a key and press Enter even if search returns no rows — you do not need a suggestion hit. On the project tab, click Add to board.

• Duplicate keys are skipped. Invalid tokens are ignored and listed.
• A board holds at most 25 epics. Extra keys are skipped with a max-limit notice.
• Newest additions appear at the top of the list.
• Remove from board drops that epic from this project only. It does not change the issue in Jira.
• Adding or removing members recaptures the period snapshot. HierarchyView tells you when that happens.
• If you cannot browse an epic, it shows as a hidden issue (Jira permissions). Other people with access still see it.

Each card shows issue type, key (linked to Jira), summary, and status. The progress chrome is shared with lookup:

• Count — percentage complete from done ÷ active children. Cancelled children are excluded from both sides.
• Pointed — the same idea, but only children with a numeric story points value. Unpointed work is ignored in this metric.
• Lozenges show done / active, pointed done / pointed active, in progress, added, removed (on the board), and cancelled.
• Show children opens the nested tree. Show cancelled and Show removed expand those lists when they exist.

Direct children load in a tree, not a paged table. Columns are Type, Key, Summary, Status, Scope, Sprint, Story Points, Assignee, and Priority. Keys open the issue in Jira.

• Click the expand control on a row (▸ / ▾) to load that issue's children. Nested levels load only when you expand them.
• An expanded branch shows its own progress bar (done, added, cancelled) for that subtree.
• Cancelled children stay out of the main tree until you click Show cancelled.
• In classic projects, if no children are found on the parent field, HierarchyView automatically tries Epic Link. Lookup shows an info banner when that fallback is used.

HierarchyView tracks delivery the way teams expect from Epic views, with extra scope awareness:

• Progress (Count) — done ÷ active children. A child counts as done when its Jira status category is Done. Cancelled children are excluded from both the numerator and the denominator.
• Progress (Pointed) — done pointed ÷ active pointed. Only children with a numeric story points value are included.
• Cancelled — children whose status matches common cancelled names (Cancelled, Canceled, Won't Do, Won't Fix, Declined) are moved to a separate section. They are not treated as done.
• Scope on the board — compared to the period snapshot: still on an epic and in the snapshot is original work; on an epic but not in the snapshot is added; in the snapshot but gone from the epic is removed.
• Scope in lookup — on first load of a parent, existing children are recorded as Original. Children created after that baseline (with a 24-hour grace window) appear as Added.

Apps → HierarchyView is for a parent you are not saving on a project board. Type an issue key (for example PROJ-42) or a summary, then press Enter or View. You do not need a search hit if the key is valid.

Results show a parent card (type, key, summary, status, description), the same progress chrome, and the nested child tree. That inspect is not added to any project board.

• Standup or weekly delivery — open the project tab. Walk the saved epics, Count vs Pointed, and anything added or removed since the snapshot.
• Planning a period — add the epics that belong in this project for the period, then leave the snapshot alone until membership should change. Reset the baseline only when you mean to start measuring a new cohort.
• A single parent that is not on the board — Apps → HierarchyView lookup. Expand nested rows if you need grandchildren.
• Classic (company-managed) projects — if the tree is empty on a known Epic, check whether children use Epic Link. HierarchyView falls back automatically; lookup shows a banner when it does.

• If Count is high but Pointed is low: is most remaining work unestimated?
• If added keeps rising: did new children land after the snapshot, and should they wait for the next period?
• If removed is growing: which stories left these epics, and was that a real scope change?
• If cancelled is large: is Done being used for work that never shipped?
• If an epic is hidden: who needs browse permission, or should it come off this board?

Keep the ritual small: maintain the project's epic list, read progress in the meeting you already have, and use lookup only when you are inspecting a parent that does not belong on the board. Install, settings, and first-time setup live in Installation and Setup.