If you are thinking about getting most out of your Jira, start here – 6 best practices for Jira fans

NB! Please note that Atlassian products are developed rapidly. The product features listed in the article may change over time.

 

If you are thinking about a Jira instance that has optimal administration fees, is scalable and user friendly, it is worth considering some of the best practices when it comes to Jira implementation and maintenance.  

 

In the following blog post we will introduce our Atlassian team’s vision about. These practices are not strict rules but rather a food for thought.      

 

 

Reasonable logic and structure of the projects

Jira projects and its issues could be observed as an active aspiration towards an objective.

 

Before implementing Jira it’s a good idea to think about all the related stakeholders in your organization – who would start using Jira, what kind of information they should provide and what would be the desired outcome.

 

Thorough descriptions of work processes and requirements is a good foundation to implement a tool the way it would meet the expectations of different stakeholders.

 

An example from TWN – we mainly use Jira Software projects to manage software development projects, to keep track on teams’ work and also to support recruitment process.

 

All the processes mentioned above have very different objectives, therefore the Jira projects supporting these processes are structured differently.

 

Reasonable project’s logic and structure brings us to Jira superuser. 

 

 

Superuser to manage Jira

The flexibility of Jira is what makes the tool so powerful, nevertheless following best practices might become complex, if different parties manage it at their discretion.

 

Our customers have named their superusers as "gods of Jira". They could be experienced Jira administrators, who: 
 

• grasp Jira as a whole;
• know how to implement end user needs to Jira concepts;
• create new and maintain existing projects with the most optimal configurations.

The superuser’s mission could be to find out what are the end user’s impediments on the current solution and/or what exactly needs to be achieved in the future before putting new requirements into effect right away.

 

Changes can be quite easily performed with a few clicks but with a big picture in mind, defining the problem and desired goal helps to create a scalable solution and minimize duplicate work.

 

Optimal configuration is tightly related to the following best practices – standardization, permission management and implementing dashboards and test environment.

 

 

Shared configurations and standardization 

As an example, let’s imagine software development projects. Software X and Y are managed in different projects.

 

The phases of work processes (the possible life cycle of an issue) are described as workflows in Jira. Every new Jira project will have its individual workflow (among other things) with default settings.

 

If the work processes for software development X and Y overlap and no other distinctions are required, it would be a good practice to associate one shared workflow with both projects.

 

If in the future there will probably be tens to hundreds of similar projects, standardization and sharing configuration elements across projects will help to reduce administrative burden and system’s performance issues. 

 

It would be good idea to use standardized and shared configuration approach also on other Jira configuration elements (issue types, screens, fields, permissions and notification schemes). 

 

And when we think about user friendly approach – for example if a project’s issue types use similar set of fields, it would be a good idea to configure them in the same order for all screens.  

This way the process of entering information would be as intuitive and smooth as possible for the user. 

 

 

Project permission management 

The permission scheme defines who can see a project’s issues and who can perform certain activities in the project.

 

If Jira groups are global, then roles are project specific. The illustration of a permission scheme below shows that the ‘Browse projects’ permission is granted to two roles.

 

Who exactly is added to these roles, is defined individually in the project settings.

 

Illustration of a Browse Projects permission.

Permissions can be granted both to roles and groups, depending on the needs.

 

For example if the ‘Browse Projects’ permission is granted to a group, then the project and its issues will be seen by everyone who are included to that group (e.g. a group with all the people in the organization).

 

However, if it is not allowed that everyone should perform activities in that project (e.g. creating issues, editing and assigning issues etc.) it could be considered to associate roles to these permissions. 

 

In addition, groups could be used in a scenario where external users join a project.  

 

Adding these users to a group and granting the group necessary permissions is probably more efficient rather than adding all external users one by one into the projects’ roles. Still, this group approach works only if all the users in the group can have the same permissions. 

 

 

Dashboards for statistics and overview 

Jira dashboard is a great way to display statistics and overview across project(s) based on desired criteria.

 

Well created dashboards help to avoid information silos and provide connected parties all the necessary information on one page. Jira dashboard permissions are configurable by editors and viewers. 

 

Dashboards display information by gadgets, that take their data from filters (a saved JQL query) or from projects.

 

For example the Assigned to me gadget displays all issues assigned to a user. This gadget takes its data from a filter „assignee = currentUser()“, which will display different data according to the logged in user who is viewing the dashboard. 

 

An example of a Jira dashboard.

 

One of the most flexible gadgets is Filter results, that displays data from a saved filter. Filters can contain various functions and combining them allows to create very detailed queries. Some examples: 
 

• project = TEST AND issuetype = Task – displays all Task type issues from the project TEST; 
• created > startOfDay("-3d") - displays all issues that were created in the last 3 days; 
• project in projectsWhereUserHasPermission("Edit Issues") AND status = Open – displays open issues in projects where a user has the "Edit Issues" permission: 
• issuekey IN updatedBy("Mari Maasikas") - displays issues that were updated by Mari Maasikas;
• issue in linkedIssues(TEST-123,"is duplicated by") - displays issues that are linked with an issue TEST-123 with a link type “is duplicated by”.

 

Although there are tens of various gadgets it is not a good idea to overload one dashboard with too many gadgets.

 

 

Test environment to test extensive changes

Many configuration elements in Jira are connected. Before implementing extensive changes in a production environment consider using a test environment beforehand to make sure everything works as expected and if needed, validate changes with users.

 

As for Jira Data Center the developer license is included with the main product. For Jira Cloud it is possible to use a free sandbox environment from Premium plan.  

 

 

Make Jira great (again) 

There is no right or wrong when implementing work processes in Jira because the specific solution is individual and what works for one might not be suitable for the other.

 

Preliminary work helps to create a vision for the desired, complete outcome and therefore it is possible to determine from the beginning how different requirements can be resolved.

 

Although standard functionalities often meet the needs, in some cases it might be more reasonable to integrate different Atlassian products (e.g Confluence or Jira Service Management) and/or implement applications.