Building an Effective Hierarchy in Jira
Configuring Jira to support a hierarchy of issue types
Overview
Jira works great with the minimal configuration at the scrum team level but there’s a greater need from Technical Program Managers and Product Managers to aggregate teamwork to larger efforts. Here are some ways to configure hierarchies successfully.
What is a hierarchy in Jira?
A Jira hierarchy is just a parent-child relationship between issues. Epics are typically groups of stories but Epics might be grouped into larger initiatives. It is important to define the depth of the hierarchy that provides value without adding overhead to the users managing the issues.
In all cases from Epic and below the hierarchy should not be changed. It is only when Epics have larger pieces of work that need to be tracked should levels in the hierarchy be introduced above the Epic.
The main audience for these upper levels is Program Managers, Engineering Managers, Directors, and Executives. For this reason, it should not impact how engineering teams work. Individual engineers and scrum teams need to spend time developing software and should not have added work in order for management to have a clear view of the world. These should be implemented in ways that are transparent to the engineers. A common complaint from engineers working in poorly configured environments is that top-down mandates increase the time they need to spend on the tool.
Sample issue type hierarchies:
Ultimately the business need will drive what the hierarchy actually is but the concept is universal.
Structure vs. Advanced Roadmaps (Portfolio)
Out of the box, Jira does not present hierarchies well. There are several plugins that have these features and two come to mind: Structure and Advanced Roadmaps (Portfolio)
Structure
Pros: Highly configurable and flexible. Supports all Jira link types. Extra Gantt add-on with better dependency management. Supports a high amount of issues. Ability to edit all fields directly in the Structure. Can dynamically pull in issues from any project based on the hierarchy configuration.
Cons: Because it’s highly configurable the learning curve can be high. This can be mitigated by creating templates where users do not need to individually configure their own Structures.
Advanced Roadmaps
Pros: Good for small teams. Fixed, easy-to-understand hierarchy.
Cons: Limit on issues and projects that can be in a single plan. The fixed hierarchy limits flexibility. Built in fields operate differently from standard Jira fields, some not being compatible with other plugins. Difficult to configure dynamic issues spanning projects.
Automation
Automation is critical to managing hierarchies. As the number of levels increases, there’s a need to update multiple issues or roll-up changes to parent issues. Adoption will be low if there is a perception that managing all these levels in the hierarchy creates more overhead.
Types of automation that hierarchies will benefit from:
Status Roll-up
Design workflows to automatically update the status of parent issues based on their children. For instance, when all Epics are Closed, then close the parent Initiative. This reduces the overhead of manually keeping parent issues’ statuses updated.
Estimate Roll-up
Similar to rolling up statuses, estimates and effort logged can roll up to see how a program is burning down from its original scope.
Hierarchy Reporting
One of the main reasons for implementing a hierarchy is to report on different levels separately. To report manually on all issues that are part of a hierarchy that is several levels deep will require complicated JQL that few will understand.
Example: There is a hierarchy with levels Portfolio, Program, Initiative, and Epic. To see all issues for a specific Program a query will need to be written that looks at all issues under that Program which is not trivial. Some plugins like Scriptrunner and even Structure and Advanced Roadmap’s built-in query functions can help but still, a user will need to be a Jira expert to compile those queries.
However, if automation is built to place the upper-level issue summaries into individual, immutable fields onto their descendants, reporting can be a breeze.
Example: For the same hierarchy as the example above, there is a “Program” field on its descendants that us automatically populated by the issues upon linking into that hierarchy. To see all Epics for a Program the query simply becomes type = Epic and Program = “Program A”
Conclusion
Working with hierarchies can be tricky but with the right architecture and automation, it can be extremely valuable to an enterprise-sized company or one that follow the scaled agile framework (SAFe). Whether hierarchies are used to group issues across organizations or for tracking large products/programs it is important to be mindful of any overhead it creates for teams using the tool.
The end result is transparent to individual engineering teams, but now Program Managers have the structure needed to gain visibility into the health of their programs.
