Enable Scrumboard Timeline view to support full custom hierarchy (Initiative-Epic-Task-Subtask)

[rlrector]

Summary

Enable Scrum/Kanban board Timeline view to support full custom hierarchy (e.g. Initiative → Epic → Story/Task → Sub‑task), aligned with Advanced Roadmaps hierarchy.

---

Environment

• Product: Jira Software Cloud

• Plan: Premium (using Advanced Roadmaps)

• Project example: BST – “BEO Systems Team”

• Board type: Scrum board

• Current hierarchy in use:

  • Initiative (above Epic, configured in Advanced Roadmaps)

  • Epic

  • Story / Task

  • Sub‑task

---

Problem / Current behavior

In our Premium instance we’ve configured a custom hierarchy in Advanced Roadmaps:

Initiative → Epic → Story/Task → Sub‑task

This works well in Plans – we can see Initiatives containing Epics, which in turn contain Stories/Tasks.

However, the Scrum board Timeline (roadmap) view for the same project/board only supports:

Parent work type (Epic) → Standard work types (Story/Task/Bug)

and explicitly does not show:

• Custom hierarchy levels above parent (e.g., Initiative), or

• Issue types below standard (e.g., Sub‑tasks).

As a result, the board Timeline:

• Ignores the Initiative → Epic relationship defined in Advanced Roadmaps.

• Ignores Sub‑tasks under Stories/Tasks.

• Shows only two levels (Epics and Stories/Tasks) even though our organization is actively using a deeper hierarchy.

This creates a disconnect between:

• The Plan (which shows our true hierarchy), and

• The team’s delivery board (which only shows part of it).

---

Why this is a problem / Impact

1. Loss of context for teams during day‑to‑day delivery
   Teams work primarily in the Scrum board. Without Initiatives in the board Timeline, they lose direct visibility of which higher‑level Initiative their Epics and Stories support. They must constantly switch back to the Plan to reconnect that context.

2. Inconsistent planning vs. execution views

   • In Advanced Roadmaps, work is organized under Initiatives.

   • On the board Timeline, that structure disappears.
     This inconsistency makes it harder to have a single, shared picture of “what we’re delivering and why” across planning and execution.

3. Fragmented communication with stakeholders
   Stakeholders often look at the board view for “what’s happening now / next”. Because Initiatives aren’t visible there, we have to explain the hierarchy using separate screenshots or Plans, instead of pointing to a single, authoritative delivery view.

4. Workarounds add friction and confusion
   To compensate, we:

   • Use naming conventions (prefixing Epics with Initiative codes).

   • Manually filter by labels or custom fields.

   • Open the Plan in parallel to the board and cross‑reference.
     These are error‑prone, don’t scale, and confuse new users.

---

Requested / Expected behavior

Allow the Scrum/Kanban board Timeline to honor the same custom hierarchy configured in Advanced Roadmaps (or at least a configurable subset of it).

Concretely, for our use case:

• Display (and allow collapsing/expanding) at least:
  Initiative → Epic → Story/Task

• Optionally also indicate Sub‑tasks in some way (even if only as rolled‑up metrics or a nested level).

Suggested capabilities

1. Configurable levels per board

   • In board settings, allow selection of which hierarchy levels appear on the Timeline (e.g., Initiative + Epic + Story).

   • Respect the hierarchy defined in Advanced Roadmaps (custom levels above Epic).

2. Nested display on Timeline

   • Rows are grouped by top level (e.g., Initiative), expandable to Epics, then to Stories/Tasks.

   • Child issues are visually nested beneath their parents on the Timeline.

3. Consistent use of the same parent/child fields

   • Use the same parent links Advanced Roadmaps uses (e.g., the Parent link field for Initiative → Epic, and Epic link for Epic → Story/Task).

   • That way, we don’t need to duplicate structure or maintain parallel relationships.

4. Board‑scoped filter remains in effect

   • The Timeline should still respect the board’s filter (project, JQL, etc.), just with the additional hierarchy context applied.

---

Example use case (BEO Systems Team / BST project)

• We manage large bodies of work as Initiatives (e.g., “Support: BEO IS&T Level 3 (2026)” in BST).

• Each Initiative contains multiple Epics, which in turn contain Stories/Tasks and Sub‑tasks.

• We already use an Advanced Roadmaps Plan to see this full breakdown.

• Our Scrum team works from the BST Scrum board and wants its Timeline to show:

  • All BST Initiatives that involve the team,

  • Their Epics,

  • And the Stories/Tasks in flight or planned.

Right now, the board Timeline can only show Epic → Story/Task, so Initiatives effectively disappear from the everyday delivery view.

---

Current workarounds (and why they’re insufficient)

• Use Advanced Roadmaps Plan for hierarchy and the Scrum board for execution, and context‑switch between them.

• Encode Initiative information into Epic names or labels, then group/filter by those on the board Timeline.

• Use dashboards/gadgets to approximate a hierarchy view, but these lack the interactive scheduling capabilities of the Timeline.

All of these are partial, brittle workarounds compared to having the hierarchy directly visible on the board Timeline.

---

Value to Jira Software

• Makes Premium/Advanced Roadmaps hierarchy more “real” to teams by surfacing it where they actually work (boards).

• Reduces friction between planning (Plans) and delivery (boards).

• Increases adoption of Advanced Roadmaps by making Initiatives visible in everyday workflows, not just in separate planning pages.

[Trudy Claspill]

Hello @rlrector 

Welcome to the Atlassian community.

As this is a user community, where users help users, it is not the best method for submitting a change request to Atlassian.

You can review their public backlog to see if such a change requests already exists:

https://jira.atlassian.com/secure/Dashboard.jspa

If one does not, I recommend that you contact your Jira Administrators to ask them to create a support ticket to submit your change request. It Atlassian accepts your change request, they will communicate back through the support ticket the link for it so you can Watch and Vote on it.

Alternately you can use the Provide Feedback option available within Jira under the Help button (near your avatar in the upper right corner). Feedback submitted there goes directly to Atlassian, but you do not get email confirmation or a link for tracking the change request.

In all honesty, though, I doubt they will ultimately implement your change request. They have already provided the Plans capability where you can create a timeline that displays the entire issue hierarchy, and where the selection of source data is flexible as a combination of any one or more of Boards, Filters, and/or Projects.