How do we create a report/dashboard on bugs by project, without making this an admin nightmare?

Hi Justin,

If I understood correctly, you want to group the bugs by project and their parent Epic (representing the roadmap items), as well as by environment (Production, Staging, etc.).

I don’t see an easy way to achieve this using Jira’s built-in reporting capabilities. One option would be to export the bug data to Excel and create the report there, but this would involve a fair amount of manual work, and the data would not be updated in real time.

However, if you are open to using an app from the Atlassian Marketplace, this can be easily achieved with the Pivot Table & Pivot Chart gadget available in our Great Gadgets app. This gadget brings Excel-like pivot table and charting capabilities directly to Jira.

To get a statistic like this, all you have to do is to add the Pivot Table & Pivot Chart gadget to a Jira dashboard  and configure it like this:

The gadget is highly configurable and customizable. You can get many other stats in form of heapmap tables or charts of various types.

Are these the stats are you looking for? I can provide more detailed instructions or we can arrange a short demo. 

Danut.

Hi @Godwin-Rousso_ Justin ,

Making the Parent field mandatory on Bug issue types sounds great in theory, but in practice, it almost always creates the exact administrative nightmare you are anticipating.

When a production defect surfaces from work that wasn't tied to an active Epic, developers or QA are forced into one of two bad choices: either create a bloated "Catch-all / Maintenance" Epic that skews roadmap reporting, or select a random Epic just to bypass the validation rule. Either way, data integrity suffers.

Here is a cleaner, two-fold methodology to track bug provenance without heavy admin overhead:

1. Shift Provenance to Versions Instead of Rigid Hierarchies

Roadmap items ultimately deliver software through releases. Instead of forcing every bug to sit underneath an Epic:

• Track Origin via Affects Version/s: Focus on capturing the deployed release where the defect was introduced. Since release versions map back to shipped roadmap increments, you can tie bugs back to delivery cycles independently of Epic hierarchies.

• Track Resolution via Fix Version/s: Use this for scheduling the remediation.

• Use Issue Links for Direct Causality: If a bug is directly introduced by a standalone Story/Task outside an Epic, a native issue link (is caused by / causes) preserves traceability without polluting your parent hierarchy.

2. Avoid "Dashboard Proliferation" with Dynamic Slicing

The biggest reporting challenge with bug triage across projects is that native Jira gadgets require you to build separate dashboards or maintain multiple static JQL filters for every combination of Project, Epic, Environment, and Version.

To make this sustainable without building dozens of reports, your dashboard needs to support dynamic on-the-fly scoping:

• Build a single centralized bug reporting dashboard (e.g., Status distributions, Assignee workload, or Resolution trends).

• Pair it with a multi-variable filter controller (slicer) so stakeholders can toggle between Environment (Production), specific Projects, Fix Versions, or Parent Epics with a single click—instantly recalculating the entire dashboard without editing JQL.

Full Disclosure: I am part of the team behind Millarum Dashboards on the Atlassian Marketplace. We designed our interactive Slicer gadget specifically to solve this problem allowing teams to slice bug metrics on the fly by Parent, Version, Sprint, Component, or custom fields from a single dashboard.

Hi @Godwin-Rousso_ Justin 

The hole you've found is structural: Bug sits on the same hierarchy level as Story and Task, and a parent has to be one level up, so a Bug's Parent can only be an epic-level item. For a bug about a story that isn't under any epic there is no valid value, and a mandatory field just makes people pick a random one.

I'd keep Parent optional and treat "no roadmap item" as a real category rather than a data error:

• Report on issuetype = Bug AND environment = Production grouped by Parent (Pie Chart or Two Dimensional Filter Statistics gadget, Statistic Type = Parent). Bugs with no parent become their own bucket, and that number is worth seeing anyway (bugs from work outside the roadmap).
• Data integrity through review instead of blocking: a filter with parent IS EMPTY AND created >= -14d checked in bug triage, or an Automation rule on Work item created that comments on production bugs without a parent asking for the roadmap item.
• If a mandatory Parent is non-negotiable, the usual answer is one standing "Non-roadmap / maintenance" epic per project. It works, but watch its count, it becomes a dumping ground.

If you also want to record which story introduced the bug when there is no epic, add a link type like "causes / is caused by". Parent stays optional; the link keeps the causal trail.

If you want the bug count next to each roadmap item's progress in one table, that's where the native gadgets stop. Disclaimer: I work for Plugio, the vendor of Plugio Suite. Its breakdown widget groups by Parent with JQL-defined metrics per row, keeps the no-parent bugs as their own row, and drills into the bug list.

Hi @Godwin-Rousso_ Justin 

Disclosure (I work for eazyBI) 

If you are willing to consider a marketplace app, that is exactly the kind of use case eazyBI for Jira is built for.

- No mandatory fields needed. eazyBI reads the existing Epic Link/Parent Link relationship that Jira already stores whenever a bug happens to be linked to an epic. At the same time, adding the parent field is not mandatory for the reporting to work. 

- Bugs without a roadmap item become their own visible group, automatically. In eazyBI's Epic/Parent hierarchy, any bug that isn't linked to an epic simply falls into a "(none)" bucket in the report. You can display it as its own row (e.g., relabeled as "Unlinked bugs" or similar) so it's tracked as a real metric, not lost or forced into a "maintenance" epic.

- Combine with Environment filtering. You can add "Environment" as a report page/row filter alongside Issue Type = Bug and the Epic/Parent dimension, to get exactly the "production bugs by roadmap item" view, while still seeing the unlinked-bug count for triage/governance purposes.

- Works across projects. Since eazyBI aggregates data from your whole Jira instance into one analytics cube, you can build a single dashboard that groups bugs by roadmap item (epic/feature/initiative) across all your projects, 

This effectively gives you the reporting outcome you're after (bugs per roadmap item, in production) while keeping the underlying Jira process light.
Here is a visual example of how it may look:

You can find the eazyBI app here, if you're willing to give it a try - eazyBI for Jira Cloud.
All eazyBI reports can be embedded directly into Jira dashboards as gadgets as well.

Best regards,
Elita

Hi, @Godwin-Rousso_ Justin 

Welcome to the community!

I believe the information you are looking for is not fully covered by native Jira gadgets today, especially in terms of hierarchical visualization and easy access to all team members. 

If you are open to a marketplace solution, I recommend Mindpro Insights. I work at Mindpro, and I believe the app can help with your use case.

It allows any user to easily create dashboards with 50+ gadgets you can choose from. The gadgets are interactive, which means that when you click on any chart segment, the entire dashboard adapts to your filter. You can also share these dashboards with internal users via a link or via the customer portal.

For example, there is an "Epic Progress" gadget that shows the information you are looking for. The gadget can be exported individually, or you can export the entire dashboard:

There are also custom gadgets that you can configure as needed. Some of them offer the option of crossing two different fields in stacked bar, line, or table format. You can also create a card to track the bugs and, by clicking on it, the entire dashboard adapts to your selection.

The app also has a "Hierarchy" filter that displays the subitems in an indented way, and the gadgets will respect the hierarchy selected:

The app is very intuitive and easy to use, so all team members and managers can easily create and configure dashboards with it.

I hope that helps.

Regards,

Eduardo

Hello @Godwin-Rousso_ Justin,

the suggestions to keep Parent optional and to treat bugs without a roadmap item as a real category worth counting, rather than a data error, seem right to me.

If you're open to solutions from the Atlassian Marketplace, JXL for Jira turns that idea into a live report without extra fields or mandatory-field rules: create a sheet from your production-bug filter, group it by Parent, and enable sum-ups to get a bug count per roadmap item. Bugs with no parent form their own group, so that number stays visible instead of disappearing.

On governance: the same sheet doubles as a triage view. Sort the no-parent group by created date and backfill parents with bulk inline editing, no CSV round trips.

Disclosure: I work on the team behind JXL.

Best regards, Martin

Hi Justin - Welcome to the Atlassian Community!

I would avoid making Parent mandatory for every Bug, because that can create exactly the data-quality problem you are trying to prevent: users may start linking bugs to the wrong parent just to satisfy the field requirement.

A cleaner approach would be to separate “where did this bug happen?” from “which roadmap item introduced it?”

For example, I would keep:

Environment → Production / Staging / etc.
A dedicated field such as Roadmap Item / Introduced By
Optionally use Parent only when the Jira hierarchy genuinely represents that relationship.

Then use Automation to reduce the manual work. For example:

if a Bug is created under an Epic, automatically copy the relevant roadmap reference;
if the Bug is not part of an Epic, allow the user to select the roadmap item manually;
if no roadmap item is applicable, use a value such as Not linked / Unknown / BAU instead of forcing an incorrect parent.

That gives you a much more reliable reporting model because the relationship you want to measure is explicit rather than inferred from Jira hierarchy.

You could then build a saved filter/dashboard around something like:

issuetype = Bug AND Environment = Production AND "Roadmap Item" is not EMPTY

and break the results down by the Roadmap Item field using dashboard gadgets or a reporting tool.

So I would treat Parent as a hierarchy field, and create a separate field for the business/reporting relationship you actually need.

That usually scales much better and avoids making project admins maintain an increasingly complicated hierarchy just for reporting.

Hope this helps!