Haut de page

What to avoid in your Jira Software implementation


Posted by
Elyes Gannoun

February 15, 2018

Jira is a very powerful tool which, when used correctly, will improve efficiency and save time. All information is aggregated in the same application, and in just a couple of clicks you can access quality reporting, KPIs and statistics.

While there are many benefits derived from Jira, it can be very difficult to maintain if you do not follow some essential guidelines. As Valiantys has over 11 years of experience deploying Atlassian tools, we know the best practices to get the most out of your team’s tools. Unfortunately, we’ve also seen practices which deter productivity. Below we’ve defined the potholes to avoid.

Limit the number of admins

Who is in charge of administrating your instance? If you give admin power to too many people, they are likely to make changes to that only benefit their own teams without necessarily having a global overview of how it impacts everyone. This is especially true if you have team members across different countries as communication is reduced. This is problematic because too many chefs in the kitchen increase the risk of configuring Jira in too many different directions, thus decreasing the product’s efficiency.

Depending on the size of your instance, give this role to just a few team members. We recommend at minimum three people (in order to make sure someone is on backup), but no more than five people.

Adopt the tool

Once you deploy Jira, you’ll need to accompany users in their adoption. Training is a good place to start, however part of the adoption process is changing their daily habits so they mostly use Jira to exchange with each other – leaving emailing behind. In fact, by keeping the option of emailing in your process, it could delay the adoption of Jira. By conversing directly in Jira, you’ll gather the information in only one place which is easily accessible to everyone, whereas email only allows sharing between a limited number of people. Likewise, if people do not know if they should refer to Jira or their inbox, it could cause confusion, loss of information and ultimately wastes time.

It is unlikely email will completely disappear, so this is why Jira offers the option to send an email notification for new messages, which you can configure in the settings. This allows for users to keep track of the conversation in Jira, yet use email to be informed when they need to respond to a message.

Keep the workflow simple

Workflows should detail the real-life processes your team uses to get work done. Because one of the main purposes of Jira is to gain time and efficiency, you’ll need to avoid long and tedious workflows that are not reflecting reality (as long processes are often simpler in real life). You should use a ten-step workflow as the maximum.

This is an example of a workflow you shouldn’t use:

 

 

I’ve seen users creating multiple final statuses such as closed, done and abandoned in their workflow. However, Jira’s best practice is to use one final status which is further detailed with the help of the resolution. For example, you’ll have a status “Closed” but with the resolution of your choice, such as Fixed, Won’t fix, Abandoned, etc. (you can create as many as you want). Remember that you have multiple native Jira gadgets based on this field, so getting the status correct is important for reporting. A final status won’t set the resolution time and therefore your ticket will still appear unresolved in every gadget.

Let’s see what happens if I cancel an issue:

As you can see, we’re in a final status, but our resolution is not set.

Our issue does not appear in your filter (looking for resolved issues on today’s date) so you’ll miss it and it won’t be taken into account in your reporting based on dates.

Contextualize your custom fields

In another matter of reporting and maintenance issues, you should be careful while using same custom fields on different projects. Creating the same-named custom field for each project will make reporting a real nightmare, because you’ll need to know the exact ID of each of them in order to differentiate them in your JQL search.

Imagine having dozens of projects and having an equal number of same-named custom fields which you can not tell apart.

Rather, the idea here is that each of your custom fields are configured differently for a given project, so that in your JQL search only one field is retrieved (instead of twelve). You can manage this on the configuration page of your custom field.

Kick-off your implementation on the right foot

Avoiding bad practices will ensure you leverage Jira as it was meant to be used. If you need more details on how to configure your Jira in order to follow the best practices, feel free to ask us questions on this page or click below to contact Valiantys’ staff of Atlassian certified consultants.