Gantt Suite for Jira v 2.1.x: Building hierarchy

Owned by Mariia Korolishyna
Sept 30, 2022
3 min read

Gantt Suite supports two approaches when it comes to building hierarchy: flexible and forced.

Internally, links between hierarchy levels are regular Jira links between a parent and a child. These links can be viewed in Jira on issue details page as is parent of / is child of relations.

Flexible hierarchy

Building this type of hierarchy is as simple as dragging & dropping children onto their parents. In example below, Story 1 was drag&dropped onto Epic 1, that made the Story 1 a child of Epic 1. The task Story 2 was drag&dropped onto Story 1. Story 3 and Story 4 were drag&dropped onto Story 2. This way we’ve got multiple levels of hierarchy.

Pros

  • Multiple levels of the same issue type are allowed. For example, a story can have another story as its parent. Forced hierarchy approach (see below) doesn’t allow this.

  • Levels can be omitted. For example, different initiatives have different hierarchy below them. So one initiative can be Initiative1 -> Epic1 -> Story1 and another initiative can have hierarchy Initiative2 -> Story2. Forced hierarchy approach allows only one hierarchy for the whole chart.

Cons

  • Levels of hierarchy aren't forced, meaning you can’t force Epics to be the upper level of Stories. A user can drag&drop an Epic inside a Story, which will effectively render the Epic as a Story’s child on the chart.

  • Only Jira tasks can be linked (like initiatives, epics, stories, defects, etc.). You can’t have hierarchy levels for data like sprints or releases.

Forced hierarchy

Hierarchy built by data grouping. To build this type of hierarchy, first, you would have to select hierarchy levels in Task grouping and hierarchy dialog.

Once this is done, chart gets organized by the specified levels.

Pros

  • forces all the selected hierarchy levels. If an Epic is placed above the Story in hierarchy dialog, then users will not be able to accidentally mark a story as a parent of an epic on a chart.

Cons

  • the same issue type can't be selected multiple times. This means an epic can’t have a child of type Epic, or Initiative can’t have a child of type initiative. If you need this, please use the flexible hierarchy approach.

  • Breaks the default hierarchy of Epic -> Task -> Sub-task. Once you add hierarchy above epics, you’ll will have to add epics, tasks, and sub-tasks as part of hierarchy too. Otherwise tasks that have children will not be visible, only sub-tasks will be shown.

  • can confuse when it comes to sub-tasks. For example, if there are tasks with and without sub-tasks, then you will see all the tasks without sub-tasks in a separate [No Parent] folder. In example below, the hierarchy is Hierarchy: Epic -> Fix Versions -> Parent. Version 2.0 has only one task with sub-tasks (DEM-10). All others have no sub-tasks, thus were placed into separate [No Parent] folder.

For more details about the forced hierarchy approach please read https://brizoit.atlassian.net/wiki/spaces/GSFJHD/pages/3186329161