-
Best Practices in Jira – Dashboard Reporting (Part 2)
Introduction
This is part 2 of the Best Practices in Jira – Dashboard Reporting which focuses more on the practical aspect. By using examples with Jira reporting gadgets, we hope to illustrate some of the points covered in the previous blog post.
The scenario is we have a Jira Software project for each Jira/Confluence app we developed to track the features/bugs/tasks. In addition, we also have a Jira Service Desk project for supporting end users.
For each Jira Sofware project, we defined 2 dashboards:
- Overall Dashboard – for high level view
- Working Dashboard – for operational view
Overall Dashboards
The Overall Dashboard is for the product owner to have an overall picture and facilitate roadmap planning. It has more charting gadgets to present high level view.
We also use the free Links Menu Gadget to consolidate all the related links on the dashboard. Team members can access the Confluence space and Bitbucket source code repository for the project from the dashboard. This facilitates new team members to get up to speed faster. You can also use it to link to the various Jira Service Desk reports.
Working Dashboards
The working dashboard is for the developers with to know the tasks they have to work to deliver the upcoming release. It contains more lists and table gadgets to show the detailed view. We also included a countdown gadget to show the time remaining to the next release.
In addition, we used Filters Menu gadget to replace the Favourite Filters Gadgets to group the JQL filters.
Support Dashboard
For the Support Dashboard, we are using a shared dashboard instead of creating 1 dashboard for each project.
By using Canned Search Gadget, users need not to write complicated JQL queries or composing their search from the Issue Navigator. They can just select the available options or enter the keywords to perform contextual searches.
A support agent can quickly find the tickets reported by a user on the phone by entering the name and optional keywords using the Canned Search Gadget.
Support Wallboard
We used traffic light colours to denote the criticality of the gadget as well to segment the dashboard. For example: Counter Board gadget (to track breached SLA) is red so that it brings attention to the viewers. The secondary information uses a subtle colour like grey.
The more important information are usually positioned at the top whereas supplementary information are arranged below.
Project View
We used Dashboard Folders app to group the dashboards in a hierarchical manner. This enable users
- to discover the dashboards available without having to find and add the dashboards one by one
- to navigate to their dashboards from anywhere in Jira
With the use of aliases, the menu entries are less cluttered without having to display their full name. It is configurable to display relevant projects only to authorised users.
Project Sidebar
We also added the dashboard links to the project shortcuts so that users can navigate to the dashboard.
It is also possible to search issues within the project using the canned search gadget.
If you like this article, you might be interested to check out our best practices series
Share this post
-
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,
- the set of dashboards and filters are also created based on the template
- The filters and dashboards are shared with the project so that people who have access to the project can access them
- Then the dashboards/filters are added to the Jira’s project shortcuts where all project members can access easily
- 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:
- review the list of public dashboards/filters and decide whether to disable public sharing
- set editing permissions for the shared dashboards
- define a set of dashboard templates for your Jira project
- define a naming convention for dashboards and filters
- 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
Share this post
-
How to integrate Sonatype Nexus Lifecycle with Atlassian Tools
Introduction
It is a fact that no software is built from scratch. Almost all of us are using 3rd party libraries to speed up the development lifecycle. Hence it is important to ensure that the open source components used are safe. Otherwise it could be the weakest link. This post introduces the possible integration between Sonatype’s Nexus Lifecycle and Atlassian toolset for DevSecOps.
Sonatype Nexus platform addresses this challenge with earlier detection of security risks/non-compliance.
The products in the suite are
- Nexus Lifecycle scans the open source components used and lists any reported vulnerabilities found. It also provides advice on which version is safe to use and the popularity of the open source components
- Nexus Firewall prevents unauthorised/unsafe open source components from being downloaded from Internet to your artifact repositories like Nexus Repository or Jfrog Artifactory
- Nexus Repository Manager caches the public components locally as well as storing the binary artifacts generated from CI/CD tools
Sonatype is a market leader in this area because comprehensive coverage and higher accuracy (less false positives and less true negatives).
Integrations
Automated scanning during builds with Bamboo
With the Nexus IQ for Bamboo app, developers can easily add a step to perform the IQ Analysis Task to the Bamboo build plan
With that, it is possible to see the scan results for each build. Developers can do comparison easily from the historical results from the Full Report link.
The Nexus IQ server will only display the latest report for each stage of each application
Policy Violation tracking using Jira
Nexus IQ for Jira app can create Jira issues for selected policy violations.
This allows the developer team to track the task easily and all the discussions and decisions are kept in context within the report.
This reduces duplicate effort and speeds up resolution time by seeing how other teams solved the issue.
The organisation is clearly structured. Each IQ evaluation is a parent issue with each affected component as a subtask.
A possible customisation will be to set the Affected Version(s) field.
Policy Violation Overview in Pull Requests from Bitbucket
The Sonatype Nexus Notifier for Bitbucket displays the Nexus Lifecycle policy evaluation information in pull requests.
With this feature, the gatekeeper can ensure that the changes introduced meet the quality and governance guidelines before merging it to master.
Conclusion
With the various integrations introduced, it is easier to ensure the delivery of quality software by empowering the developers throughout the various stage of development.
Security should be everyone’s responsibility
Share this post
-
Get Ready For 2017 With The Right Tool
“You are only as good as your tools”
If you are using tools like IntelliJ IDEA, Resharper, PyCharm, RubyMine or WebStorm, this might be useful info for you.
Share this post
-
Powering your Dev Teams Contest #2
We are organising a series of contests for the IT folks in Singapore.
For this month, 10 lucky winners with the correct answers will get to win a Allocacoc PowerCube Remote Original + PowerRemote each.
The submission will close on 31 August 2016 2359hrs Singapore time
Terms and Conditions for the contest
- This contest is open only to citizens and permanent residents of Singapore aged 21 and above.
- No purchase is required. Contestants will have to like our Facebook page
- Limited 1 entry person. Subsequent entries will be disqualified.
- Each correct entry will be limited to 1 lucky draw chance.
- The winners of each lucky draw will be picked from all eligible entries.
- The qualifying period for this draw is 1st August 2016 – 31st August 2016.
- The lucky draw will be conducted electronically on 15th September 2016.
- Winners will be notified by 16th September 2016 via a prize notification email.
- Lucky Draws winner are required to respond within a week from notification date in order to be eligible winners. Winners that do not respond will be forfeited.
- We reserve the rights to deal with all unclaimed prizes in any manner deemed fit.
- Any personal information collected is for the sole purpose of conducting the Contest including the notification of the winners of the Contest. By participating in the Contest, participants consent to the Organiser’s use of their personal information in accordance with the terms and conditions of the Contest.
- We are not a supplier of the product(s) offered and shall not bear any liability in relation thereto.
- Akeles’ decision on all matters relating to the draws shall be final, binding and conclusive and no correspondence will be entertained.
- Participation of the Contest constitutes acceptance of the terms and conditions of the Contest.
Share this post
-
How teams uses Atlassian suite to get work done
Continue ReadingThis short video gives a good introduction on how teams use various Atlassian products to get work done
- Confluence – for team content creation and sharing
- JIRA Software – for team planning and project management
- JIRA Service Desk – for team services and support applications
- HipChat – for team messaging and communications
- Bitbucket – for team code sharing and management
Each of them work well individually and can integrate seamlessly with a consistent user experience and richer feature set
Subscription Options:
