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

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.

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.

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.

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.

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.

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.

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.