What is Jira and Why Should I Be Using It?

If you’ve never used Jira (or any other issue tracking software) then allow me to introduce you to Jira. If you are an existing user, hopefully I’ll be able to share a few practices that may be of benefit to you and your environment. This article provides an introduction to Jira and it is really part of one a series of using Jira. The details covered here are crucial to understand if you are a current user, hoping to use Jira, or are looking to gain adoption within your team. While Jira happens to be one of the most popular issue tracking systems on the market, many of the competitors function in similar ways so you should be able to apply these practices to your environment.

A little bit of history

I’ve worked for a number of companies over the years in software engineering, analytics, and management capacities. What I’ve found is that a number of analytics departments frequently overlook the benefit of utilizing issue tracking software. When I first started working at a major US company, I must say that I was a bit shocked to learn that an issue tracking system wasn’t being used by almost any analytics team. Now it’s not like we were talking about 1995. This was in 2016 and I still see the lack of use today. The exception to this lack of usage was within the data engineering team but I wasn’t surprised because they function more like software developers which is why I advocate for analysts to function like developers. But before we dive into Jira and issue tracking systems it would probably be good to level-set on how the analyst functions on a day-to-day basis.

A typical day might start out with an analyst having someone drop by her desk to ask for “a super easy request”. This analyst, probably a little interrupted with her day, listens to the requestor and agrees to do the work. Maybe she starts working on it right away or maybe she takes a note that she needs to work on this request at a later date. But where does she store the note? Is it in her head, in a paper notebook, in a Microsoft sticky note on her laptop? It’s anyone’s guess but this does create some challenges. If she’s writing all of these tasks on paper, she’s probably going to have to flip between pages from different days to see all of the open tasks that she has. Or maybe every day that she comes to work she has to re-write all of her tasks on a new sheet. Neither of these options are efficient and it would be pretty easy for her to accidentally forget about a task.

When add in all of the other sources of requests that come through email, Slack, Teams, meeting action items, drop-by, and other systems, tracking tasks gets very messy in rapid fashion. But even though the analyst has developed a pretty good system of managing her tasks I can confidently say that it probably isn’t as efficient as using and issue tracking system. Furthermore, when you broaden the scope from one analyst to include all analysts on a team, managers, stakeholders, and any future employee that might need to know about any historical context related to a request, using anything other than an issue tracking system is going to offer less than desirable results.

What is Jira

In the most simplistic sense, Jira is an issue tracking system but it is designed to help you stay organized, plan projects and your workday/workweek, and provide valuable information as to what work was performed, how it was performed, and why it was necessary. There are many other features and plugins that can be bolted onto Jira but that’s more advanced functionality that is out of scope for this article. Below are some of the benefits that you’ll realize from using Jira.

The benefits of an issue tracking system

As I’ve alluded to, there are many benefits of using an issue tracking system. Here’s a short list of what you’ll get with Jira:

• Single location for storing all of your tasks
• Digital storage — eliminating the need for re-writing items on paper
• Ability to search for any to-do tasks or historical tasks
• Ability to search through any of the notes, outcomes, associated code, dashboards, requesters, etc. related to the task
• Prioritization of tasks
• Task level-of-effort estimation
• Time tracking
• Ability to assign tasks to individual, call out mentions to others, and include watchers on tickets
• Automatic notifications any time notes or status’ are updated on tasks
• Project management capabilities
• Customized visual organization and tagging of tasks
• Ability to relate tasks to other tasks
• Ability to link tasks to code in Git
• Customized reporting — useful for displaying what has been accomplished, how much work is in the pipeline, or resource deficiencies
• Visibility to other individuals in the organization and management

Who shouldn’t use Jira and why you shouldn’t use it

Honestly, I can’t think of hardly anyone that couldn’t benefit from Jira and I can’t think of too many reasons why you shouldn’t use it. Jira can be used by Marketing, Software Development, Analytics, Customer Service, and many other teams to keep track of their tasks. However, at times that are definitely other tools that are better suited for different types of work. Jira just happens to be really good at keeping track of tasks within the software development space, including analytics. I’ve used plenty of other tools and I hop between tools depending on my needs. For example, I used to love (and I still do) using Trello. It’s extremely easy to rapidly create new tasks and there usually aren’t a lot of required fields to complete. Just type a couple words for your task and you’re done. It’s also very easy to organize your tasks. However, in a corporate setting, Trello always falls short for me because I need a tool that is built to scale with my environments. Meaning, I have to be able to customize certain fields, connect tasks or units of work to other units of work, and provide easy search, assignability, context, and data governance and security. Trello just doesn’t offer all of those things but it is great if you’re working on some small teams. Microsoft also has their version of the Trello *card* look and feel in Microsoft Planner.

In summary, if you’re a tiny team in a non-corporate setting and you don’t intend to scale and don’t care about being able to do advanced searches and connect information from one task to another, then you can probably get away with using something other than Jira. It will be faster and slightly easier. However, I have yet to walk into a software or analytics space where I didn’t want to use Jira. Even on my own personal development projects where I’m the only person writing code, I use BitBucket which has tickets that look a lot like Jira. I only use Trello for project management tasks (such as planning a party) that will never involve me writing code.

Common Resistance and Objections

Like anything new, people are going to throw up resistance and objections. And like most objections to change, most of these reasons will not be valid or be supported by facts because, well, these people are new to the product and haven’t actually tried using it. Over the last 14 years of using issue tracking systems I’ve encountered plenty of people in the analytics domain that have been resistant to using Jira but the objections were completely invalid. A part of me feels that with some objectors, the only way that they will ever learn the value of Jira is to spend a number of years in uber frustrating situations under tight deadlines all because someone didn’t take the time to write a few extra sentences regarding their work. However, I’m hopeful that maybe I can convince a few readers here and save as many people as possible from the pain of frustration.

Here are a few of the more common, non-factual objections:

1. “It takes too much time to create a ticket” — With the most basic ticket, filling out the very few required fields it only takes about 30–60 seconds to create a ticket. I’d be surprised if individual contributors were consistently creating more than 5 tickets on a daily basis.

2. “I’ll spend too much time updating and commenting on tickets” — While it’s true that you’ll spend more time updating tickets, I’m not sure that it is *too much time* is an accurate statement without understanding the value that is created by using Jira. When used correctly, analysts will have to allocate time updating comments (more on this later) but they will have to make many of these updates anyway in some sort of verbal or email communication so the additional level of effort is marginal at best and the benefits far outweigh the cost.

3. “It’s too much overhead” — Jira is minimal overhead, especially given the benefits. Every individual contributor has to keep track of their tasks, whether it is on paper, mental notes, or in an issue tracking system. Only the issue tracking system can offer all of the benefits described above and I really can’t think of much overhead to Jira. The only place that I’ve seen this so-called overhead is when a Jira administrator creates a number of required and custom fields that must be completed to open a ticket. However, in almost all cases, those fields were absolutely necessary to the business.

4. “We’re too small of a team” — Even with a team of 1 person, Jira is useful. If you’ve ever wondered, “Why did someone write the code this way?”, “What is the purpose of this code?”, “Who should I talk to to ask questions about this dashboard or report”, Jira is useful. But how is it useful if you’re a team of one person? Well chances are you’re going to leave the company and someone else is going to inherit your work. When they do, they’re going to have questions and Jira will be there to provide many of the answers.

Users and Audience

After hearing these common objections (and many more) time and time again, I realized that maybe the objections are being surfaced because the objector (mainly an individual contributor) isn’t looking at the problem from the right angle. Here’s the key thing to remember about Jira. It’s not about you; it’s about everyone else. Okay, so maybe that’s not completely accurate but it’s pretty close. Most of the time it’s about everyone else and sometimes it’s about you.

While Jira was built as an issue tracker and functions well as a task management system, a lot of discussion is around the individual contributor and how they create and update tickets. Many new users that I’ve trained through my career have felt that commenting in Jira is too much work and at first they don’t usually understand why they need to add any comments. For example, let’s say that you have a sql file (eg. quarterly_report.sql) that is used to generate your company’s quarterly report. This quarter a member of the finance team emailed the analyst and asked him to update the exchange rates that he is using to generate the report. This seems like an extremely simple request and it only involves a couple of keystrokes. Honestly it takes more time to open up a Jira ticket for this request than it does to make the actual code change. So the analyst just makes the change (hopefully they are using “Git and making writing good comments”), produces the report and all is well.

Fast forward to next quarter. You’re a new employee and you just got asked to update the exchange rates in some report. Unfortunately, the analyst that made the changes last month is no longer at the company and neither is the person in finance. Where do you start? Well, you might go look at a dashboard where this information is being reported but that dashboard isn’t a lot of help because it’s not like the dashboard tells you where to find the data. So you navigate to the dataset that is backing this Tableau dashboard but it takes a long time to see the sql that is being used. Eventually Tableau shows you the dataset and you know what query or table the data is coming from. But again, it’s not like it tells you *how* to update anything. Off you go to investigate this table.

With knowledge of the table that the dashboard uses you can query the table data, but again that isn’t very helpful. You don’t know how any of that data was inserted into the table and you surely won’t learn that by querying a table. Next you decide to search your internal documents and wiki pages but like most organizations, documentation is lacking and out of date. After hours or days of searching you find someone who can tell you about the ETL script that was created to populate the table. You breathe a sigh of relief because the next part should be easy. You’ll just open the sql, update the rate, save the file and call it a day. But again, nothing is ever that simple.

After opening the file you find that there are almost zero comments in the code and you find that there are obscure variable/field names, poorly formatted code, and multiple exchange rates. You spend hours trying to figure out what is the right thing to modify to ensure that you don’t break anything. Finally you know what to change but again, another hurdle. What exchange rate should you populate anyway? Nobody bothered to put any sort of notes in the code about where this number originated from. Do you just go out to Google and find the latest exchange rates? Does Finance have a rate that you should use? Again, you find yourself spending your days hunting down this information and eventually you find your answer, update the code, and call it a day. What was supposedly a 5 minute task took you two weeks to understand and complete. All because nobody documented anything along the way.

Again, this is the critical point and it’s worth repeating: The tickets and documentation isn’t for you; it’s for everyone else. Yes, Jira can be about you and it provides some very good software for keeping you organized but there are so many other people (current and future) that will want to understand and search for this information. Here’s a few things that other people need depending on their role:

Managers

• Need to understand how many tasks are in an individual team member’s queue. If the manager doesn’t know this then 1. the manager might overload the team member. Team members aren’t going to appreciate being bombarded with work and managers aren’t going to be happy with work that keeps slipping to future dates.
• Need to be able to teal their managers what is happening on the team and what work is planned
• Need to understand future tasks so that they can properly plan for headcount and budget

Project Managers

• Need to be able to see dependencies so that they can plan a timeline for when work will be completed
• Need to see all tasks so they can adjust for resources, time, or scope

Requestors

The person that needs the work completed needs visibility into the progress and status of the work. Think of an auto mechanic, doctor, or anyone else that performs a service for you. If you went to this person and said, “Something is sounding funny with my car”, imagine if they simply ignored you or maybe just said, “okay, we’ll look into it” and provide no additional information. I’m almost certain that you’d want to know 1. what do you think the issue is, 2. how long do you think it will take to diagnose (because I need to find out how to do without my car), 3. how much might this cost, 4. how long might it take to fix, 5. what the real problem, 6. how much did it cost, 7. When can I pick up my car? These are general expectations but when it comes to work requests, many people forget how important it is to keep the end-user up-to-date with the latest information. Jira helps with sending the emails upon status changes but the person assigned to the ticket needs to make frequent and sufficient comments

You, the task owner

• Need to be able to show your value to management and the company. Jira makes it easy to look back throughout the year and report on all of the work that you’ve accomplished. I’ve used this functionality as a manager when writing annual reviews for my direct reports and I’ve had my direct reports use this when they write their own annual reviews
  Need to stay organized and deliver on-time. Without Jira, it’s hard to keep track of all of your tasks and it’s easy to drop the ball on items. Jira will help to reduce some of the challenges with day-to-day task management.
• Need to be able to take notes on your work so that you remember where you left off and so that you can follow up on projects. Many times you’ll be working on multiple tasks and will need input from others. Jira is a great place to take notes such as, “Reached out to Amber via email to gain clarification on exchange rates to use in our report for Q4 2019. Awaiting feedback.” With a comment like this, next time you look at the ticket you’ll have your reminder to follow up with Amber so that you can complete your work.
• Retain information about key contacts, steps to complete the task, and other relevant information. For example, let’s assume that you were asked to rewrite a report for the Finance team. Regardless of how simple the report is there are some crucial questions that will be asked at a later date. Some of these questions might be:
  
  • Who asked for this to be changed
  • Why did we need to make this change
  • When did we roll out this change
  • Who made the change
  • Did it go through a quality assurance review
  • What were the quality assurance tests and steps
  • What data was it validated against
  • Where’s the proof that this all works
  • Where’s the proof of what code you actually changed so that I can tell that you didn’t accidentally change something else
  • If there is a bug, will we be able to trace it back to this change

Future owners

Much like my example above, a future owner is going to need this information. The trouble is, you don’t know who the future owner is, what their knowledge or skill levels are. It’s best to avoid trying to read minds and just document your work in the ticket since everyone can search it at a later date. Even if you assume that you’ll always be the owner, you’ll probably need to go back to the item or answer a question about how and why something was done in the event of a bug or a feature request.

Again, I’ll reiterate, if you aren’t thinking about everyone else and the importance of having notes about how and why a task was performed, I’d encourage you to read over all of this again and think of all of the times that you spent days or weeks on a project, hunting down people and information, all because an answer wasn’t at your fingertips. Yes, it might take an extra couple of minutes for you to update a status in a ticket but to the future use(s) they can and will spend hours, days, weeks, and months hunting down answers. This time far outweighs the few minutes spent updating your status. Also, I’d argue that by not updating your status in a ticket, someone is asking you about it anyway in a meeting or email so writing updates isn’t costing you time; it’s actually saving you time in the long run if you write clear comments in your tickets.

In my next article all talk more about how to actually use Jira and some of the best practices that I’ve worked with.