Transform a love-hate relationship between JIRA and Agile to a love-love

[#1]

“Where there is great power there is great responsibility” – Winston Churchill

I love JIRA. As an Agile Coach, I love that I can bend it to my will and really customize it to make sure it isn’t an evil tool forcing my teams into a process rather than supporting their process. For just about everyone else, that customization is why they hate JIRA.

Just because you can configure something doesn’t mean you should. We’ll focus on three areas that can quickly become a nightmare: Permissions, Transitions, Custom Fields and Ticket types.

Permissions

Last week we spent ten minutes in Sprint Planning trying to figure out why the ScrumMaster couldn’t start her sprint. Turns out the filter query they use to determine what is part of the team’s backlog isn’t project specific, but permissions are. A ticket ended up in their backlog that she didn’t have permission to edit due to its project permissions so had lost admin privileges to the board. Frustrating? Beyond!

There are good reasons an organization should lock down permissions on a project, especially if there are security or personnel information concerns. For example, your HR team is using a JIRA project to track their initiatives, which include bonus and/or raise information on employees. These should be hidden. Completely reasonable. However, having edit permissions doled out individually based on your team is incredibly hard to manage and cumbersome.

Permissions can be granted based on various criteria as seen below. This gives admins the ability to create a tangled web of permissions. There are absolutely things that should be locked down. Administering projects should be reserved for project leads and deleting certain things like comments or attachments may be something you want to limit, but most permissions don’t need to be specified. The easiest way to accomplish this is to use “Application access” > “Any logged in user”. Translating to: If you can login to JIRA you can do these things.

If you need to provide some types of users permissions while disallowing others, creating user groups and having users automatically given permissions across projects based on their role is much easier to manage and leaves a lot less room for error. You may want to add individuals as project administrators, but developers and users should be added by group. If you don’t find the need to distinguish between users and developers, simplify even further and only have one group.

Transitions

Visualizing your workflow is extremely important. Forcing every single ticket to go through each step of the workflow is torture. If your workflow works like the one below collaboration is constantly punished. 

As agilists we drive teams to collaborate rather than throwing things over the wall, which means  workflow steps may not be linear if even used at all. In the example above, though, if statuses are “skipped” you must spend the time to transition your issue through each and every step. It’s tedious. It makes developers hate working in JIRA. We have to stop doing it. You can easily accomplish this by checking  “Allow all statuses to transition to this one” when adding a status step to a workflow or editing one.

Custom Fields and Ticket Types

Finally, the two features that are possibly the biggest love killers are overuse of custom fields on a ticket and entirely too many ticket types to choose from. Sure, you can create dozens of ticket types with hundreds of custom fields. You can add tabs to tickets to group those fields. You can even make the fields required. How much fun is that?!?! If you are anyone required to either create or read tickets on a daily basis the answer is, “absolutely none!”

I once worked with a JIRA instance that had 73 custom fields (of which a good portion were required), spread across 3 tabs on the “User Story” ticket type. Let the irony of that sink in for a minute. JIRA is supposed to be a tool that supports teamwork. If something that is meant to be a placeholder for a conversation requires that much information, you are probably using it as a replacement for a conversation.

There is an art to adding custom fields and ticket types. They can be amazingly useful if you limit the number of ticket types per project and the fields on each ticket to only those relevant to what you need. If your company is really using JIRA across multiple departments adding new ticket types and fields is absolutely necessary. The HR department will likely need a ticket type of Candidate, if they are tracking their recruitment process rather than Story or Bug. That Candidate ticket type can then have the appropriate custom fields of “Candidate Name” and “Salary Requirements” that don’t belong on a Bug ticket.

Inside a software project, limiting a “technical task” ticket type to only a couple of fields to ensure it is just as easy as writing on a sticky note will remove barriers to entry for your team. The goal is to limit the choices people need to make and the required fields truly relevant.

The meat and potatoes of JIRA management is trust, communication, and simplification. Do you trust your team to do the right thing and manage themselves appropriately or are you trying to use a tool to enforce practices and rules? (If you are using JIRA to enforce your process rather than to support it, you have some things to discuss that JIRA can’t solve for you.) Are you providing a space for team members to collaborate or giving them a crutch to avoid communication? Does your JIRA instance require your colleagues to think to use it, or are the choices they need to make intuitive and truly necessary. You have the power, use it for good.

This article was originally published here: http://upraise.io/blog/jira-and-agile-relationship/