How to create an additional issue hierarchy

In Jira, bigger tasks can be split into smaller pieces; thus, we can create task groups that are linked together but can be worked on separately. For example, an Issue can be grouped into smaller sub-tasks. Or an Epic can be split into Stories. eazyBI recognizes those structures and creates different standard hierarchies in the Issue dimension:

  1. the default hierarchy with ProjectIssue levels,
  2. the Sub-task hierarchy with ProjectParentSub-task levels,
  3. if you have imported the standard Epic Link field then also
    the Epic hierarchy with ProjectEpicParent , and Sub-task levels.
  4. if the Advanced Roadmaps is used, and Parent Link and Epic Link fields are imported then the fourth hierarchy is created based on the Advanced Roadmap configuration (on the Cloud you need to enable the integration and add the hierarchy configuration, see here)

Also, in Jira, there is an option to use issue links to create a relationship between issues; some apps use this to allow Jira users to build even more issue hierarchies. Also, eazyBI offers an option to create an additional issue hierarchy in the Issue dimension. Those additional issues hierarchies need to have a strict structure in Jira to be defined in eazyBI:

  1. Each child issue has only one parent issue
  2. Each issue type is used only in one issue hierarchy level.

When you start building the additional issue hierarchy based on issue links, a few important things have to be taken into account. Here I will only mention what in the configuration is different from the simple issue link dimension. But if you are not familiar with issue links and how to import them in eazyBI, you can check this article.

  1. The issue link dimension for any next level should be described from the child’s perspective.
  2. There is only one parent issue; thus, the multiple_values parameter should never be true.
  3. You will need the “update_from_issue_key” parameter to pass the value to children’s issues.

Here is an example of a hierarchy from Jira’s perspective:

  • Improvement
    • → Feature
      • → Epic
        • → Story/Bugs
          • → Sub-tasks

Here is how it looks in Jira:

  1. “Improvement” issue type: PO-1

  2. “Feature” issue type: PO-3

  3. “Epic” issue type: DA-12

And here is how it can be configured in eazyBI advanced settings. The issue “Improvement” hierarchy is built on top of the “Epic” hierarchy by adding two additional levels “Feature” and “Improvement”. Each link should represent the one level above - define “Improvement” from a “Feature” perspective, define “Feature” from “Epic” perspective and pass the value down to children issues with “update_from_issue_key”:

##Issue is child of Improvement
#import reference to Improvement for Feature
[jira.customfield_improvement]
name = "Improvement"
inward_link = "is child of" #link name and direction from Feature perspective
issue_type = "Improvement"
dimension = true
update_from_issue_key = "customfield_feature" # pass down values to children of feature

##Issue is child of Feature
#import reference to Feature for Epic
[jira.customfield_feature]
name = "Feature"
inward_link = "is child of" #link name and direction from Epic perspective
issue_type = "Feature"
dimension = true
update_from_issue_key = "epic_key" # pass down values to children of epic

## Issue hierarchy Improvement
[[jira.issue_hierarchies]]
name = "Improvement"
all_member_name = "All Issues by Improvement"
levels = [
  #two custom levels above default epic hierarchy
  {name="Improvement",key_column="customfield_improvement",issue_type="Improvement"},
  {name="Feature",key_column="customfield_feature",issue_type="Feature"},
  #default set of levels for epic hierarchy, do not change it
  {name="Epic",key_column="epic_key"},
  {name="Parent",key_column="epic_parent_key"},
  {name="Sub-task",key_column="subtask_key"}
]

In this use case to create a new issue hierarchy, in the eazyBI data source import options field “Improvement” and “Feature” needs to be selected for importing. After the import, a new issue hierarchy is created.

The report “Issue custom hierarchy improvements” is based on the configuration above:


Remember that you should build an issue hierarchy based on one of the two default hierarchies (Epic hierarchy or Sub-task hierarchy). Parameters update_from_issue_keys and bottom levels of the hierarchy should be of the same default hierarchy and should be used with the default setup. Build any level on top of those bottom levels.

  1. Rules for defining update_from_issue_key correctly:

    • when defining any higher-level link custom field, link it to the field storing the issue key of the next lower issue-level

    • if the next lower level is Epics and the hierarchy is defined upon epic hierachy, use
      update_from_issue_key = "epic_key"

    • if the next lower level is a standard issue level (parent) and the hierarchy is defined upon sub-task hierarchy, set
      update_from_issue_key = "parent_issue_key"

  2. Rules for defining the bottom levels of the hierarchy correctly:

    • use those as bottom levels if the hierarchy is defined upon Epic hierarchy
    {name="Epic",key_column="epic_key"},
    {name="Parent",key_column="epic_parent_key"}, 
    {name="Sub-task",key_column="subtask_key"}
    
    • use those as bottom levels if the hierarchy is defined upon Sub-task hierarchy
    {name="Parent",key_column="subtask_parent_key"}, 
    {name="Sub-task",key_column="subtask_key"}
    

See other issue hierarchy examples as well as troubleshooting steps in the documentation: Additional Issue hierarchies

1 Like

Hi Gerda -

Thanks for the response. Some of what you mentioned makes sense to me, but I’m confused by other parts. I’m familiar with the Gantt chart view and have used it before, but this isn’t really what I’m looking for. I’m not concerned about any time constraint here, Basically, we’re using a pretty standard hierarchy in Jira and Advanced Roadmaps, which looks like (top down):
Theme → Initiative → Epic → Story → Sub-Task.

I have the Parent Link (for Epic to Initiative) and Epic Link (for Story to Epic) in place…see the screenshot. For this report, I’m not concerned about FixVersion. Instead, we have a custom field called ‘Program Increment’ which is being applied at the Initiative level. We use this to plan Initiatives into PIs and then everything linked under those Initiatives is considered part of the PI.

So, I want to see story points rolled up to an Initiative (planned/committed) and then see an inline stacked progress bar of how many points are closed vs not closed. Might even be cool to see stacked points by story status (i.e. In Progress, etc.). The goal is to have a report which shows all Initiatives in the PI and the progress of each based on underlying Epics → Stories. Ultimately would be nice to see 2 views: one by % complete based on closed points and another based on % complete based on closed story count. Basically, similar to what Advanced Roadmaps shows (see 2nd screenshot following this post).

I’m not clear on how to accomplish this but it seems like it should be doable? If you can give me some more specific guidance on what I may need to add such as custom measures, etc., that would be fabulous. FWIW - we are using Jira Server Edition with Advanced Roadmaps plugin, all on premise.

Let me know if any of that is not clear.
Thanks!
Drew

Hi @drewwiseman,
If you import “Parent Link” and “Epic Link” in your eazyBI account, you will have an “Advanced Roadmap” hierarchy in the Issue dimension. eazyBI will sum up all the measures on any higher level.
If you create measure “Story Points resolved %” in Measure dimension using this formula:

CASE WHEN
  [Measures].[Story Points created] > 0
THEN
  CoalesceEmpty([Measures].[Story Points resolved],0)
  /
  [Measures].[Story Points created]
END

Then add it to your report and get this type of report where the progress is calculated from the children’s issues at the parent level:

Also, you can add other dimensions in Pages to filter issues by some parameters. Check if those fields are inherited from parent to children issues. In case the fields are only at Initiative level, not inherited, and are single select fields then you can create an issue link filed dimension, see more here: JavaScript calculated custom fields

Kind regards,
Gerda

Hi Gerda,

Thanks for the help and sorry for the delayed response as I was out on vacation.
I took your suggested and created the custom measure, but used ‘closed’ instead of ‘resolved’ as that is more appropriate for us. I can’t seem to get this to work however and I’m not sure why. Please see the screenshots for my configurations.

Also, I want to leverage the linkage through the hierarchy (parent link, epic link, etc.) to get to the Program Increment field that I have on the Initiative. I do not want to put this PI field on the lower level items (Epic, Story) as we don’t need them there for our business purpose and it’s too much maintenance overhead. I simply want to filter on Initiatives in a PI and “gather” all of the underlying Epics, Stories to get my story points. I hope that is doable, as I can do it in Jira with nested queries…but need it in an eazyBI report. And yes, this is a single select field. Can I create this link field dimension without having to put the custom field on the Epic and Story? I hope so.

Please let me know if that does not make sense or if you have any questions about what I’m trying to accomplish.

With Regards,
Drew



Hi @drewwiseman,
You measure “% of Story Points Closed” displays a result of 44%. Can you share more details on why you think it is not working correctly?

If you are marking measure “Issue type” on your print screen as the measure that is not working, then it is working as expected as it won’t show any data at the “All Issues” level. You need to expand that member to see the information about each particular issue member. “Issue type” is issue property and is visible in the report per each issue separately.
You can learn more about issues, properties, and measures in this presentation (aproxm. 4:10min): Training videos on specific topics

And about the PI field, if it is a single select field, then you can create a javascript field in eazyBI, so the PI children know what value PI is holding, and thus you will be able to filter the report by it (without adding the field to PI children in Jira). See the instructions here: JavaScript calculated custom fields
Also, you can find a solution on the community; see this post:

best,
Gerda

Hi Gerda,

Thanks again for the help! I realize when I look back at my post that I wasn’t clear enough, sorry about that! So regarding the first half of my post about points, I spent some time testing this out today and here’s what I found: it does seem to be working. I just need to make 2 tweaks to get the data right.

  1. Need to exclude issues with specific resolutions. For example;
    a) closed with resolution = duplicate
    b) closed with resolution = duplicate
  2. I need to exclude any sub-tasks that are pointed. Longer term I am going to remove the story points field from the sub-task as it doesn’t make sense for our operation. But for now, if I can just filter these off that would be good.

What is the best way to modify my custom measure to filter off the sub-tasks and the issues (story, bug, task) with specific resolutions? Here’s an example of one of my measures:

“Story Points Remaining”
CASE WHEN
[Measures].[Story Points created] > 0
THEN
CoalesceEmpty([Measures].[Story Points created],0)

[Measures].[Story Points closed]
END

Thanks again for the help!
Drew

Also - I am investigating the PI (Program Increment) solution. Thanks for that!
Drew

Hi @drewwiseman
you can add your dimension “Resolution” and “Issue type” in pages for filtering. In the “Resolution” dimension, create an aggregate member that excluded “Duplicate” and “XXX” values using this formula:

Aggregate(
  Except(
    [Resolution].[Resolution].Members,
    {[Resolution].[Duplicate],
    [Resolution].[XXX]
    }
  )
)

In the “Issue type” dimension, you can use the hierarchy “All Issue types by type” → “Standard” that would exclude all sub-tasks from your report (this is available on eazyBI Cloud or on Server/DC starting with version 6.4):

The calculation will adjust accordingly to your filter results.

best,
Gerda // support@eazyBI.com

Gerda,

This is brilliant! Thank you!

Drew

1 Like

This is a great walkthrough, but I’m banging my head against the wall trying to troubleshoot my implementation. I’ve set up a custom hierarchy placing a level above Epic called “PI Objective” and tested a couple of different link types. I’ve tested “is blocked by” as a more specific link type, but you’ll see below that I’ve also tested with “relates to” in both inward and outward directions. Somehow the report is only showing me Epics under the Objective where the Objective itself is a child of that Epic (this is erroneous and will be cleaned up later). I tried specifying the issue types in the “Parent” level of the hierarchy under Epics, but that doesn’t seem to remove the PI Objectives issue type from this level. Furthermore, I don’t see the other Epics linked to the PI. What am I doing wrong?

[jira.customfield_objective]
name = "PI Objectives"
inward_link = "relates to"
outward_link = "relates to"
issue_type = "PI Objectives"
update_from_issue_key = "epic_key"

[[jira.issue_hierarchies]]
name = "PI Objective"
all_member_name = "All Issues by PI Objective"
levels = [
  {name="PI Objective",key_column="customfield_objective",issue_type="PI Objectives"},
  {name="Epic",key_column="epic_key"},
  {name="Parent",key_column="epic_parent_key",issue_type = ["Story", "Bug"]},
  {name="Sub-task",key_column="subtask_key"}
]

I worked this out with Gerda via support. Turns out I was not properly clearing the data by unchecking the custom fields in the source data > importing > checking the fields > re-importing.

Also the Epic Link relationship indeed causes the odd behavior seen in my case. Also have multiple parent Objectives causes equally odd behavior where those Objectives are combined into a single row.