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 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!