Struggling to Build Cross-Project Jira Reports with Calculations

[#1]

I ran into this while trying to answer fairly simple questions across multiple Jira projects: totals, averages, and trends over time. Things like “How many story points did we complete per project?” or “How does throughput compare across teams?” sound straightforward, but quickly become painful in practice.

Jira’s native dashboards work fine as long as everything stays inside a single project and doesn’t require real calculations. The moment reporting needs to span multiple projects, I found myself exporting issues repeatedly, rebuilding the same pivot logic in spreadsheets, and redoing the work every time someone asked for a slightly different cut of the data. That manual loop became the real bottleneck.

The problem wasn’t visualisation. It was that the data and calculation logic lived in too many places and couldn’t be reused across projects.

Why Native Approaches Break Down

Jira reporting is designed around per-project scope. Most gadgets assume a single project context, and even when cross-project JQL is allowed, calculated values and aggregations don’t persist in a reusable way. Each dashboard gadget effectively becomes its own isolated configuration.

Atlassian Analytics improves flexibility, but it still requires building logic repeatedly at the chart level and doesn’t solve the underlying issue of centralised, reusable aggregation logic across many projects. As the number of projects grows, the reporting model simply doesn’t scale.

A Practical Approach That Worked

What finally worked was stepping back and changing where the logic lived. Instead of trying to force calculations into Jira dashboards, the approach was to move aggregation and calculation into a shared reporting layer before visualisation.

Using Visionade, the idea was to build a single cross-project dataset. Calculations weren’t tied to individual gadgets anymore. They lived at the Data Set and Report configuration level.

This works because the heavy lifting happens before anything hits a dashboard. Projects, metrics, and trends are all defined once in a central dataset, and reports simply reuse that structure. The dashboard becomes the final display, not the place where logic is rebuilt every time.

Setup Approach

• Start by creating a Jira data source that includes all relevant fields like Project, Status, Issue Type, Story Points, and any custom fields, and ensure those fields are indexed for aggregation.
  

• Build a Data Set using a cross-project JQL scope (for example, multiple projects in a single query) so all issues live in one consolidated view.
  

• Preview the Data Set to confirm that issues from all projects are present and that grouping fields are available.
  

• Create a Report from this Data Set, placing Project in Column, Assignee in Row, and calculated metrics in values.
  
  

• Add the saved report to a Jira dashboard so it stays up to date automatically.
  

Result

Once this was in place, cross-project reporting stopped being a recurring task. Calculated trends updated automatically, dashboards stayed consistent, and new questions didn’t require rebuilding everything from scratch.

The key takeaway for me was that Jira dashboards work best as presentation layers. When aggregation and calculation logic move into a shared dataset, cross-project reporting becomes far more manageable. Hope this helps others running into the same limitation.

---

I’m from the Visionade team, and this content was written with the assistance of AI. I’d genuinely be interested to hear how others approach reporting in Jira.

If you’d like to explore this approach further, you’re welcome to try Visionade - we hope it provides a useful and positive experience: Visionade: Reports, Dashboards, Graphs, and Charts for Jira 

[orla_mears]

Hi @Duong Nguyen Hong ,

Good topic thank you - this is something that has piqued my interest as I move to a new role in the coming weeks and anticipate that I will be building out a lot of analytics/insights for my new teams.

One thing that I wanted to ask was:  with Filter options native to Jira, I can build out a filter to include the Key ID, story points and assignee. I can also add in multiple projects/spaces to the JQL rule.

From there, I could then create a dashboard (using something like Custom Charts) and group by assignee and sum of story points.   I feel there's also additional opportunities to build out more filters/dashboards to show individual team performance and show these side by side.


What can I ask does this app give that native Jira won't?

[Hung Tran Manh]

Hi @orla_mears ,

Great question – and you’re absolutely right.

For many common use cases, native Jira + JQL + dashboards (or marketplace apps like Custom Charts) can already cover a lot:

• Filtering by key fields (assignee, story points, status, projects, etc.)

• Grouping and aggregating data for basic team-level insights

• Building side-by-side dashboards for teams

In those scenarios, Jira works well, and we usually tell customers the same.

Where we typically see teams start to struggle is when:

1. Analytics needs go beyond Jira issues alone

Jira dashboards are great for issue-centric views, but become limiting when you want to:

• Combine Jira data with Table Grid data, external metrics, or derived fields

• Create reusable datasets that can power multiple reports without duplicating JQL logic

2. Data modeling & consistency become important

As dashboards grow:

• JQL rules get duplicated across gadgets

• Small JQL changes can silently break multiple reports

• Different teams interpret the “same metric” slightly differently

Visionade focuses on defining a single source of truth dataset, then building reports, tables, and charts consistently on top of that.

3. More flexible reporting & presentation is needed

Visionade is useful when teams want:

• More control over how data is transformed (calculated fields, custom aggregations)

• Reports that are easier to read for non-Jira-power users (PMs, leadership, stakeholders)

• Tables and charts that are easier to evolve as questions change

So in short:

• If your needs are mostly issue-level and Jira-native → Jira dashboards may be enough

• If you’re building broader analytics, combining datasets, or scaling insights across

teams → that’s where Visionade adds value

Happy to dive deeper into a concrete use case if you have one in mind 

If you have sometime next week, can we have a call between our Visionade team and you so we can get a better understanding what you are looking for in our app?

Regards,

Hung

Visionade Team