![]() One of the main reasons for implementing a hierarchy is to report on different levels separately. Similar to rolling up statuses, estimates and effort logged can roll up to see how a program is burning down from its original scope. This reduces the overhead of manually keeping parent issues’ statuses updated. For instance, when all Epics are Closed, then close the parent Initiative. Types of automation that hierarchies will benefit from: Status Roll-upĭesign workflows to automatically update the status of parent issues based on their children. ![]() ![]() Adoption will be low if there is a perception that managing all these levels in the hierarchy creates more overhead. As the number of levels increases, there’s a need to update multiple issues or roll-up changes to parent issues. AutomationĪutomation is critical to managing hierarchies. Difficult to configure dynamic issues spanning projects. Built in fields operate differently from standard Jira fields, some not being compatible with other plugins. Fixed, easy-to-understand hierarchy.Ĭons: Limit on issues and projects that can be in a single plan. This can be mitigated by creating templates where users do not need to individually configure their own Structures. Can dynamically pull in issues from any project based on the hierarchy configuration.Ĭons: Because it’s highly configurable the learning curve can be high. Ability to edit all fields directly in the Structure. Extra Gantt add-on with better dependency management. There are several plugins that have these features and two come to mind: Structure and Advanced Roadmaps (Portfolio) Structure Out of the box, Jira does not present hierarchies well. Ultimately the business need will drive what the hierarchy actually is but the concept is universal. 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. These should be implemented in ways that are transparent to the engineers. 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. For this reason, it should not impact how engineering teams work. The main audience for these upper levels is Program Managers, Engineering Managers, Directors, and Executives. 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. In all cases from Epic and below the hierarchy should not be changed. It is important to define the depth of the hierarchy that provides value without adding overhead to the users managing the issues. Epics are typically groups of stories but Epics might be grouped into larger initiatives. What is a hierarchy in Jira?Ī Jira hierarchy is just a parent-child relationship between issues. Here are some ways to configure hierarchies successfully. 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. Photo by Kelly Sikkema on Unsplash Overview
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |