In the previous post, I went through my opinionated view on top 10 anti-patterns using jira. This one will focus on getting most out of Jira.

What does getting most out of Jira means ?

It means using Jira in a way that it helps you making better decisions and communicate clearly, supported by transparency and useful data. As we see in the previous post, it’s very easy to use Jira like a big basket of sticky notes, which always ends up being a garbage.

Overview

There will be many voices trying to show the best way to use jira. Some will try to use as much feature as possible, integrate it with as many places as possible. This approach rarely works out well.

Overall, keeping things simple and stupid will help here as well. We must always remember that, jira (or any other issue management system) is a lean waste. They don’t add value. However, issue management systems are essential for collaboration and external communication. (One person team might as well be fine with a notepad) So it is a necessary waste that needs to be kept under control.

Necessary wastes must be under strict control to contain their impact on the overall value stream.

1. Customizing the workflow

All issues have 3 basic states that we all know:

• To Do
• In Progress
• Done

This basic, linear flow applies to all situations as minium. There is no more granular state exists. Even if you are blocked, or decide to park a ticket after the work is started, it is actually still in progress. The simple explanation is, once the clock starts, it doesn’t stop until done or cancelled.

However in real life, value-streams are rarely this simple. If the goal isn’t simply keeping track of what needs to be done, if the goal is also figuring out inefficiencies, bottlenecks, wastes in order to refactor our flow, customized workflows are the way to go.

JIRA allows us to design a workflow that can accurately map the real life situation. This is the best case scenario because issue management tools that don’t reflect the reality as is, hide problems. We would generally want to make problems clearly visible.

2. Tracking the time in ‘blocked’ state

Like in many other queues, software engineering pipelines lose their effectiveness when they are blocked. Bottlenecks are primary concern therefore visualizing them and raising awareness using data, is a great way to grab the focus and motivate everyone to solve it.

3. Limiting the issue types used

Jira comes up with default issue types and allows users to create their own. Unless really needed, inflation of issue types typically create more confusion. (Endless -and useless- debates whether an issue should be a story, new feature or change request) It is best to keep the types limited.

If someone wants to create a new type, we should ask the question:

“What kind of decision that will contribute to the final product will you take, when this new issue type created?”

4. Automation

Jira, like many other issue management systems, support great deal of integrations. Nobody likes clicking buttons of jira so whenever manual jira action can be done by automation, it should be done.

The best example is endless bugging of engineers to click start button so the issue can switch to in progress state. This is necessary, we need this data, but it is also a labor that is often forgotten.

Integrating jira with our scm, in a way that, a feature branch (or even fresh new development envinronment) is created when issue switches to in progress state saves bunch of clicks/commands.

5. Learn JQL and data model

JQL is one of the most unique, powerful features of Jira. Ability to use a query language that is very much like good old SQL, is immensely powerful for managing issues. Beyond that, JQL can be extended with custom functions that add features not existing out of the box. You can write your custom plugin that allows access fields of the data model that is not exposed by JQL or install plugins.

6. Use swimlanes with JQL

Swimlanes are grouping of issues based on a criteria, that all flow from a To Do state to all the way towards completion. Although hard coded swimlanes (eg: epic) exist, the actual power comes when we create swimlanes using JQL. Some examples:

• All the issues (you might have external dependencies too) that you have to finish for a specific customer demo (this is neither a version, nor an epic)
• All the issues that have target SLA < 1 day for resolution
• All the issues that are raised by your most important customer with a severity higher than X.

7. Automatically create issues, but only if you can close also automatically

Automatic creation of issues are helpful to eliminate manual work. It can happen when our monitoring system detects a serious problem, or a security issue found in a library or trunk is broken. Organizations that require tickets for those should look for an integration that would create and resolve those tickets automatically. Such integration can provide useful data to be recorded while requiring noones manual effort.

8. then priority

Stick with arbitrarybacklog order,

9. Experiment with custom priorities

As with other options, jira allows us to define custom priorities other than blocker, critical, major etc.

Such adjectives often cause confusion amongst people. What is really critical ? What is minor ? We document those in some pages but there might be shorter ways.

Do not afraid to be creative for such priorities: *

10. Use control chart

Control chart, in my opinion, is the best and most useful chart of jira. Together with good configuration of quick filters and swimlanes, it allows us to transparently see our lead and cycle time with averages and standard deviation.

This chart alone, should be used by engineering leaders to understand how the productivity of the team is changing over time, and set/track goals for improvements.