Issue hierarchies
eazyBI for Jira
On this page:
Overview
eazyBI supports several hierarchies in the dimension Issue. The default hierarchy uses Issue grouping by the project. eazyBI imports a Sub-task hierarchy to group sub-task issues by standard issues. For Jira Software projects we support Epic hierarchy if Epic Link is imported into eazyBI. This hierarchy works similarly to the Sub-task hierarchy with additional grouping by Epics. In addition to default hierarchies, eazyBI supports hierarchy for Advanced roadmaps and building new custom hierarchies.
eazyBI will sum up all the measures on any higher level. You can use any measures, for example, Issues created, Issues resolved, Story Points created, Original estimated hours, Hours spent, or any custom field measure, and eazyBI will sum up values from sub-task and standard issues up to any higher level in the hierarchy.
Be careful using additional dimensions in Pages or Rows. eazyBI will show issues and their place in the hierarchy (via parents) based on those dimension selection. It will not show children issues if they will not match those selections. For example, In the Epic hierarchy, Issue type selection Epic will show only epic issues and will not show issues in epic (children).
You might want to use values on epics (or other higher level issues) to limit data in the hierarchy report. eazyBI by default options are limited. You can use:
- define custom formulas to access epic values for all issues in epic and then use it as a filter.
- define and import Issue link field dimension and use it on the report instead of default dimension
- define and import calculated JavaScript inherited dimension and use it on the report instead of default dimension
Issue link field dimension and calculated JavaScript inherited dimension require custom advanced setup from Jira admin. However, the reports will require less customization and would be easier to maintain and create.
The report building principles for any Issue hierarchy are similar to the examples described for Epic hierarchy. You can use any of the imported hierarchies to build similar reports.
Issue Epic hierarchy
This example will show how to create a basic report to represent a hierarchal data structure of issues using Epic hierarchy as an example.
This report uses the Issue dimension Epic hierarchy. The report uses project level. We suggest using hierarchies on the highest-level reasonable for the particular report use case. You can always expand to see more details. Select the needed level in two ways:
Expand the Issue dimension menu in Rows selection, then expand section All hierarchy level members and select the needed level from the relatable hierarchy. Another way is using a table report, then click on the Issue column header and select the All hierarchy level members from there and then use a level selection of the hierarchy. Both options will make the same selection.
The report contains
- Issue properties Issue type, Issue priority, Issue assignee, Issue due date, Issue story points
- Measures Story Points created, Original estimated hours, Remaining estimated hours, Hours spent, Issues created.
There are no data for Issue properties on the Project level, Issue properties show values for individual issues only. Measures are summed up from sub-tasks to parent issues, epics, and projects.
Please check the property Issue Story Points and Story Points created. Expand one project, and one epic to stories. Issue Story Points is a property and shows results per individual stories, Story Points created is a measure and it gives a total for Epic and Project by default. Other properties, like Issue type, Issue priority, Issue assignee, Issue due date represent values for particular issues. They do not aggregate by default.
The report uses the option drill into for measure Issues created to show the progress of issues by status category.
The report uses several Pages selections. Pages selections will pull related issues and show results for higher-level issues as well. It will not show child issues, though. For example, filter by Issue type Epic will show only epics and you will lose any details for Stories, Bugs, and Subtasks. Selection by Issue type Story will show data by stories (issues created, original estimated hours, hours spent). It will show the totals for related epic as well. But it will not include data from sub-tasks.
See the description for the Sprint and Epic gantt charts to see how you can use custom measures as filters by Epic status.
Issue Epic hierarchy for epics in progress (issue link field dimension)
This report example is from the eazyBI Demo Training account and it requires additional configuration. Jira admin or eazyBI admin would like to define and import issue link field dimension Epic status to get this report to work. This example describes how to define and use Issue link field dimension Epic status for filtering issues in the report based on epic status - Epics in status category In progress.
Issue link field dimensions support passing down several default Jira field values to issues in the hierarchy. For this example, the Issue link field dimension Epic status should be defined in eazyBI advanced settings:
[[jira.issue_link_field_dimensions]] name = "Epic Status" source_dimension = "Status" issue_id_column = "epic_id" group = "Linked issue dimensions"
Add the definition to eazyBI advanced settings or ask Jira administrator or eazyBI admin to do this for you. eazyBI advanced settings are common for all accounts and only Jira administrators and eazyBI admins have access to the settings. Then import the newly defined issue link custom field into the account. It will be available for import in tab Additional options > section Issue link field dimensions.
Then the new dimension Epic Status will be available in the account in the dimension sub-section Linked issue dimensions. Issue link field dimension is similar to the default dimension. In this case, the Epic Status dimension works similarly to the default Status dimension. The report uses Epic Status dimension Category hierarchy in Pages with a selection of statuses from the status category In Progress.
Report uses
- Issue properties Issue type, Issue priority, Issue assignee, Issue due date
- Predefined measure Issues created
- Report specific calculated measures Due date, Bugs, Stories, Standard issues
Report specific calculated measure - Due date
This measure uses the issue epic hierarchy explicitly and pulls the latest due date from all child issues.
TimestampToDate(Max( -- access issue itself and any children of a specfic Issue hierarchy Descendants([Issue.Epic].CurrentMember), -- transform due date to timestamp to get a numeric argument for Max function DateToTimestamp([Measures].[Issue due date]) ))
Report specific calculated measures Bugs, Stories
Measures Bugs, Stories are similar and use measure Issues created in a tuple with specific issue type either Bug or Story. They will show issues with a specific issue type explicitly in the report. This is an example of Bugs created:
([Measures].[Issues created], [Issue Type].[Bug])
Report specific calculated measure Standard issues
This measure counts bugs and stories created in the epic. Measure iterates through issue types with function DescendantsSet. This will allow you to Drill across > Issue type if you would like to split by issue type Bugs or Stories.
-- this measure will count stories and bugs in total: Sum(Filter( DescendantsSet([Issue Type].CurrentHierarchyMember, [Issue Type].CurrentHierarchy.levels("Issue Type")), -- filter only the needed issue types [Issue Type].CurrentHierarchyMember.Name MATCHES "Bug|Story"), -- use measure as a counter and filter [Measures].[Issues created] )
The report uses Drill into > Status by Category > Catagory level to split the total count of bugs and stories by status to see the overall progress in the epic.
See also
- Learn about calculated measure creation.
- See more about options that are available when you create a report.
- Learn how to modify different chart types.
- See training videos to learn more.