Getting the Most Out of Jira: Preparing for Powerful Reporting

[Alexey]

Numbers guide our decisions every day:

• "How many burgers should I prepare for the weekend barbecue?"
• "Is it cold enough for a jacket?"
• "What is the ETA to get home in this traffic jam?"

When it comes to managing projects, the numbers and visual data in Jira are equally vital. As we start using Jira, we often don't think about reports initially. We might not know how our reports will look or how Jira will evolve within our organization. However, after a few months, we may encounter challenges related to reporting and data consistency.

But what if we could avoid these potential difficulties?

Atlassian Admins are in a unique position to lead the conversation about preparing and planning Jira reports. Their expertise in the tool and understanding of best practices can lay the foundation for forecasting and planning future KPIs and reports.

Here are some ideas to plan and prepare Jira for successful reporting:

1. Identify Critical KPIs: Understand the key performance indicators that are crucial for your organization. Knowing what to measure is the first step in generating meaningful reports. Atlassian Admins can initiate discussions with stakeholders from various departments and teams to draft the most important metrics.
2. Group Reports by Target Audience: Different stakeholders need different information. Understanding the most important KPIs can lead to the planning of team-oriented dashboards. For example, delivery teams can benefit from daily progress reports, while senior leadership might be interested in a high-level overview with forecasts and trends.
3. Ensure Consistency in Jira Custom Fields: Consistency is key when setting up custom fields. Atlassian Admins can develop a strategy to ensure that information in Jira projects is as consistent as possible. This involves repurposing existing Jira custom fields whenever possible, instead of creating new ones (or at least creating a new context for the existing field). Each request for new Jira custom fields should be evaluated against a list of existing fields to determine what can be reused.
4. Share Custom Workflows: Standardize and share workflows and statuses across teams to maintain consistency in processes and data collection. This approach ensures Jira issues follow a consistent list of statuses. For example, statuses like “Completed” and “Done” would be duplicates to avoid if we want to run reports against issues in the final status.
5. Continuously Tune and Refine Reports: Regularly review and adjust your reports to ensure they remain relevant and accurate. As your organization evolves, so should your reporting.

By proactively preparing Jira for reporting, you can streamline your project management process and avoid common pitfalls. With these strategies, Atlassian Jira can become a powerful tool for insights and decision-making.

What is your favorite approach for successful reporting in Jira?

[Haddon Fisher]

My favorite approach to reporting in Jira is to use Google Sheets.

[Andreas Springer {Actonic}]

Interesting. Why is that and how do you even do that? 🤔

[Andreas Springer {Actonic}]

@Alexey Good advice, thanks for sharing!

[Haddon Fisher]

It's always been a bit of a challenge to get good insights out of Jira. It's definitely getting better, but at the end of the day I've still found a need for Sheets.

• Realtime only - Jira itself only makes the "current state" of datapoints available, so it's impossible to track anything over time.
• Getting the Set - Just getting the set you need can be a challenge in and of itself. You can't generally work with more than 1,000 issues at a time, and some data-points are simply cannot be exposed.
• Calculated\derived data is hard - Outside of specific instances, there's not a real concept of calculated data fields or rolling up within the tool itself. You can build some of these some of the time using Automations....assuming your sample set is less than 1k issues, you have spare executions, have effective maintenance\change management processes, and they actually run all the time.
• Dashboards are limited - I've seen dashboarding make a tremendous organizational difference (go visit a Bloomberg LP office) but you're probably not going to do that with Jira. All of the reasons above make getting the data you need already a challenge, but the functionality of dashboards itself is not great. Rich Filters does a fantastic job mitigating as much as is probably possible in Cloud, but it can't do anything about the underlying data problems, let alone things like layouts or slowness.
• No non-Jira data - There's no data store area in Jira, so it's very hard to incorporate data-points that are needed but don't source from within the application itself.

The quickest and easiest solution I've found depends on the report, but in general:

• When tracking things over time (such as delivery of roadmap items across a group of software development teams in a quarter), I'll export the same filter results every couple of days, pasting them into a running tab to create a flat database. In other tabs, I'll use functions like FILTER or QUERY to create views from that data. Usually it's on the team, cluster, program, initiatives as well as other useful lenses like "issues with bad or missing data" and "initiatives with more than 50% scope increase".
• When creating more artifact-based reporting (such as calculating capitalizable vs. operational expenditures for a group of software development teams in a month), I'll export the data I need and put into distinct tabs and then build the report I need in separate tabs. This allows me to clone the sheet, replace the base and\or mapping data, and get the same report with the same business logic.

[Elizabeth Nixon]

Hi @Alexey and thanks for this helpful information! You talk about setting up and using consistent custom fields. It's my understanding that with team-managed projects in Jira, each project is self contained and custom fields in one project aren't available to reuse for other projects; we have to create the custom fields for each team-managed project. Is my understanding correct? Is there any other way to more easily duplicate the settings (including custom fields and statuses) for one team-managed project into another one?

Ensure Consistency in Jira Custom Fields: Consistency is key when setting up custom fields. Atlassian Admins can develop a strategy to ensure that information in Jira projects is as consistent as possible. This involves repurposing existing Jira custom fields whenever possible, instead of creating new ones (or at least creating a new context for the existing field). Each request for new Jira custom fields should be evaluated against a list of existing fields to determine what can be reused.

[Haddon Fisher]

Elizabeth Nixon there will still be issues trying to cross-project reporting using TMP's, but it is now possible to use instance-wide fields in a team-managed project.

[Alexey]

Hello @Elizabeth Nixon 

Thank you for the great question. I understand your challenges regarding the unification of data from Team-Managed Projects.

There are two approaches that can be taken. Let's take a look at both of them:

1. Organizational Approach: If several Team-Managed Projects frequently need to report on consistent data, it might be worth considering merging them into one Company-Managed Project or moving them into different Company-Managed Projects with consistent custom field setups. This approach ensures that reports are also consistent.
2. Technical Solution (with EazyBi): For example you have Team-Managed project "Team Project 1(TEAM1)" and "Team Project 2(TEAM2)" with similar select field "Car Model". In "Team Project 1" values for the field are "Honda", "Toyota" and similar field in the "Team Project 2" are "VW","BMW"   .
   1. In the "EazyBi" you can created new account and import data from both project. You will get two dimensions "Car Model(Team1) and "Car Model(Team2)"
   2. Than you need to create new custom measures than will unify data from both fields into one custom measure.
   3. After this you will be able to report data in the single column.

Please let me know if you have any questions.

[Elizabeth Nixon]

@Haddon Fisher I'm only able to find documentation on global fields for JPD, even though JSWCLOUD-20905 initially solved for Jira Software which is what I need. Do you have any suggestions on where to find documentation on how it works for Jira Software?

[Haddon Fisher]

Elizabeth Nixon I am not sure about Atlassian-generated documentation; it feels like it should be on this page, but it clearly says the opposite...maybe out of date?

However doing it should be pretty trivial:

1. Open your team-managed project, and go to 'project settings'
2. Go to 'issue types' and select the issuetype you want to add the field to
3. The right-side should have a panel split into two sections. The top part allows you to make new fields, but below that you should see "Search All Fields". This should give you access to fields that live in this project and any instance-wide fields that have a global context.
4. Find the field you want, and drag it into the section you want it displayed in. You'll notice most of the field options are greyed out.

Note: You cannot context instance-wide fields to a team-managed project, so any field you want must have a global context.

[Daniel Szewczyk]

First of all, reporting shouldn't be a work that Jira Admins do, but rather people who are specialisied in data analysis and reporting, so relevant access to the data should be available for such roles.

Secondly, as someone pointed out, only current state of data is available in Jira with very very limited capabilities of JQL to reach out to historical data. Everything that is currently available in the Ticket history should be searchable with JQL, otherwise it's not too useful.

Dashboards are poor in terms of functionality and they look as if they were developed and styled 20 years ago. There are only a few usecases these can handle and as such are not commonly used.

The only viable option to work with data from Jira is to pull all of the ticket information daily to external solutions and process and report on that data there. Of course I'm not saying that Jira should be as specialised and flexible as for example PowerBI, but let's not overstate that Jira is a "powerful tool for insights and decision-making".