Best Practices in Jira – Dashboard Reporting

Introduction

Jira Dashboards is a very powerful feature if used correctly. In this article, we will share with you the common pitfalls as well as some best practices based on our experiences as an Atlassian Solution Partner. 

Why people use Jira Dashboards 

Dashboards can be from a macro perspective like % of project completion to micro level on the list of tasks with their statuses. 

Some common use cases for Dashboards are:

• monitor the progress of the tasks
• track the KPIs and the health of the project
• highlighting important stuffs (e.g. SLA breach, bottlenecks, shortages) for action taking
• show progress to motivate the team

More organisations are preferring dashboards over reports because of the following reasons:

• live information – able to see the current status which is more accurate
• time saving – there is no need for someone to spend time to compile the weekly/monthly progress reports manually
• interactive – as compared to a chart image in a PPT/PDF
• allows drilling in – you can zoom into the details of the issue for more information
• self reinforcing – it encourages people to update their Jira issues regularly

Common pitfalls and recommendations

Security / Information Disclosure

From our Jira consulting experiences, there are a number of instances where the dashboards and filters are accessible by users without logging in.

Although Jira’s permission scheme will prevent public users from viewing the issues, it is still possible to disclose sensitive information which may not be meant for public eye.

You should check whether there is information disclosure by logging out of Jira and visiting the URLs

• Dashboards – https://<jira-base url>/secure/ManageFilters.jspa
• Filters – https://<jira-base url>/secure/ConfigurePortalPages.jspa

Unless the dashboards/filters are for public access, users should not select Public for the Add Shares option.

Tip: There is a “Sharing with anyone on the web” in Jira configuration which you can disable to remove the Public option if your Jira instance is not for public access.

Performance and utility

Another common pitfall is people tends to create 1 dashboard for each project and cramp everything inside. We have seen a dashboard with over 20 gadgets added. As a result, it clutters the dashboard and is slow because it has to load a lot of information. This can also slows down the Jira instance for other users.

From a design point of view, this is bad because it introduces a lot of noise in the dashboard. As a result, people cannot zoom into the important things that they need to take action from the dashboard.

A well designed dashboard should fulfil the following:

• Targeted for the role/purpose – A management report should not include the micro information like the list of tasks. Likewise a developer will be more concerned about the list of tasks he needs to work on. You can create different dashboards for different roles.
• Incite emotion or action – it should bring attention to the readers to take any necessary action. With correct use of colours and placement, users can determine the severity easily.
• Easy to understand – It should use the correct type of gadgets to present the information in the most direct manner. You can check out the list of Jira gadgets available on Atlassian Marketplace.
• Responsive – it should be fast to display the information without the reader having to scroll through many screens to read the entire page.

Discoverability

A dashboard is useful only when there are people using it. Another common pitfall we observed is that every user tends to build their own dashboards. While this is flexible, there are some disadvantages like:

• duplicated effort to create and maintain the dashboards
• decreased utility since only 1 person is using it
• some users are unaware on the types of gadgets available that they can use for reporting
• some users lack the proper training on how to write complex JQL queries and design good useful dashboards
• no standards on the performance metrics to monitor within the organisation

To tackle this, we advocate to design a set of dashboards as a template for every Jira project. When a new project is created,

1. the set of dashboards and filters are also created based on the template
2. The filters and dashboards are shared with the project so that people who have access to the project can access them
3. Then the dashboards/filters are added to the Jira’s project shortcuts where all project members can access easily
4. They can also be added to the Dashboard Folders and Menu Gadgets so that users can easily navigate to the reports

Maintainability

Another common problem that Jira admins face is obsolete dashboards/filters. By default, only the original creators can edit their dashboards/filters.

From Jira 7.12 onwards, it is possible to grant permissions for other team members to edit filters/dashboards. Hence a useful tip after creating a filter/dashboard will be granting permissions to the associated project roles

• to grant view permission to all project members
• to grant edit permission to the project administrators

Naming Convention

We also recommend to define a naming convention for filters and dashboards. E.g <Jira project key> – <purpose>.

This is especially helpful for users when they are searching for a filter when configuring the gadgets. For very large instances, you can find multiple filters with the same name while selecting a filter for a gadget.

It is possible to define aliases for dashboards and filters with Dashboard Folders and Menu Gadgets.

System Dashboard

When a user adds a new dashboard themselves, the system dashboard will disappear.

Actually the System Dashboard is very important because it is tedious to go through the list of project dashboards.

The System Dashboard can complements by

• providing a consolidated view and highlight the important things that matters to the user
• as well as a landing point where the user can navigate to other places

Conclusion

In conclusion, here is a checklist that you can use:

1. review the list of public dashboards/filters and decide whether to disable public sharing
2. set editing permissions for the shared dashboards
3. define a set of dashboard templates for your Jira project
4. define a naming convention for dashboards and filters
5. install apps from the Marketplace that you identified that are useful

---

Check out Best Practices in Jira – Dashboard Reporting (Part 2) for the continuation of the writeup.

If you like this article, you might be interested to check out our best practices series

• Best Practices in Jira Administration – Jira Apps Management
• Best Practices in Jira Administration – Be a Jira Hero ebook