nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Godwin-Rousso_ Justin

My organization is trying to understand how many bugs are being introduced by our roadmap items.

Our initial solution was to make the environment fields and parent fields mandatory, so that we can then report out on any bug where the environment is production and is tied to a parent. However, we are worried about what to do when a bug is for a ticket that is not part of an epic.

How can we reliably provide the organization with a report of bugs per roadmap item, without making this an administrative nightmare and ensuring data integrity?

Accepted answers

All comments

Habib__Plugio__

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.

Godwin-Rousso_ Justin

This is a good suggestion. We will be utilizing parent (to tie a bug back to and epic and therefore a specific project) and make the environment a mandatory field so that when we report on bugs that we have this information.

My next question is about governance. Is there a good way for us to enforce this? I don't know how we stop the nonroadmap / maintenance epic a dumping ground. That is why we were wondering if there was a better solution than parent linkage and utilizing the environment field.

Thank you for your insight!

Jovânio Junior

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!

Laura Marin - Millarum

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.

Natasha Roumanoff - Cloudscript_io

For me, stopping the nonroadmap / maintenance epic from becoming "a dumping ground", is less about a product issue and more of a human behaviour issue. I'd solve it with a custom field (something like "root cause" with a single select list of options) and then adding a requirement that if a bug ticket does not have a value for parent epic then it cannot be moved to done without a value being provided for the custom root cause field. The options for this field could be a few general containers that work for bugs not usually related to a feature (eg "library upgrade", "unforeseen interaction between features", "infrastructure change"...), that way if your tester hasn't managed to identify a feature that the bug is related to (via the parent epic) then the developer needs to give some indication of what caused this once they have solved it. The dev could also simply assign a parent epic if they worked out that this is the feature that caused it when solving the issue too. The custom field should aim to catch all bugs that are introduced by things that are NOT necessarily roadmap items, but might need a bit more analysis after the fact (eg if you know feature X required an infrastructure change in release Y, then you could count all tickets from that release that selected this root cause as being caused by the feature).

Danut M _StonikByte_

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.

Martin Sturm - JXL

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.

Grouping work items with counts per group

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

Eduardo Anflor - MindPro

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:

Screenshot 2025-05-22 at 11.36.47.png

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.

Screenshot 2026-01-30 at 17.49.35.png

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

Screenshot 2025-05-12 at 10.56.57.png

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

Elita Kalāne - eazyBI Support

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:
Issue-Epic-hierarchy-Issues-Jira-Demo-eazyBI-09-04-2026_04_46_PM.png

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

Habib__Plugio__

Hi @Godwin-Rousso_ Justin ,

A few options, from softest to strictest. They combine, and which mix fits depends on how much friction your teams accept:

Make it visible. Keep the maintenance epic but time-box it (one per quarter, named that way) and give it an owner. A dashboard number like parent = MAINT-123 AND created >= -7d next to the per-epic counts shows when it's filling up. No enforcement, just nowhere to hide.
Nudge. An Automation rule on Work item created for production bugs without a Parent, commenting and tagging the area lead. Cheap, catches the honest forgetting, doesn't stop the lazy pick.
Enforce at the right moment. The reporter usually doesn't know the roadmap item at creation, so leave Parent optional on the create screen and require it later: give Bugs a Triage status and add the native Field required validator with Parent on the transition out of Triage (company-managed workflows support Parent there). The bug can't move to the backlog until someone who knows the roadmap has placed it. This is the one that actually stops the dumping ground, because the person making the choice is the one accountable for the report.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

reporting