9 Jira Best Practices – The Jira Guy

Reposted with permission from The Jira Guy

While not hard and fast rules, these concepts can help you find your teams’ best solutions. A friend of mine suggested this topic, and I loved the idea. However, I was having a problem finishing out the post, so I had to turn to the community for more ideas. And you guys delivered! As such, I’ll be putting the source (or sources) I heard of these rules from. So let’s dive in and see what we can learn here!

# 1 – If your workflow takes > 30 seconds to explain, it’s too complicated

– Logan Hawkes (Coyote Creek Consulting)

So, this one is relatively straight forward. The idea is that your workflow should be simple enough that you can explain it quickly to your colleagues. If your workflow sounds like “First it goes here, then it gets assigned to this person. However, if this thing is checked, then it’s assigned over here instead. After that, it goes back here for approval before going here to have some action performed, and then it’s transferred to that department for final analysis.”

A workflow you can’t explain effectively and can’t maintain easily does no one any good.

# 2 – If your workflow +10 steps, it’s too long

– Logan Hawkes (Coyote Creek) & Matt Doar (LinkedIn)

So this is another rule of thumb meant to protect you from an overly complicated workflow. The idea is simple – if your workflow has too many steps, your users will not want to use it. No, seriously, put yourself in your user’s shoes. Would you like to progress through a workflow that has twenty or thirty steps? I have better things to do.

The number is a bit arbitrary, but it’s about spot-on. More than ten and your workflow starts to look like a mess.

# 3 – If you have to scroll + 2x on a screen, it’s too long

– Logan Hawkes (Coyote Creek)

This one also goes into the same category. Having too many fields on a screen doesn’t capture any more useful data, discourages your users from using the system, and all-in-all just looks terrible. But where do you draw the line? What number is “too many” and what is “just right.”

That’s where this rule tries to help. Rather than giving a hard number, it gives you some criteria. Two scrolls will vary user to user, but it’s close enough to provide you with leeway in making your screen.

# 4 – If you have > 1000 issues in your backlog, it’s a history book, not a backlog.

– Sean Blake (Easy Agile)

I have seen this all too often, and I’m sure you have, too. That project that collects backlog issues like they are a collector’s item, with the “Yes, we’ll do all this someday” attitude.

If this rule of thumb applies to you, it’s time you had a hard conversation about reality and priorities. It’s time you decide what you do intend to do, what are lovely ideas but not feasible, and what you need to mark as “Won’t do.”

It might also be time to look at your process and add a triage step to filter out some noise from entering your backlog. Otherwise, you’ll wind up back here in a few months anyway.

Let me make myself clear here. If you take in public submissions for bugs, feature requests, etc., you’ll find this number to be laughably small. However, this rule of thumb isn’t meant for these kinds of queues. It’s intended for your team backlog, which should never grow that long with work waiting to be done.

# 5 – If you need something more than labels and components to divide your work, review your process.

– Jesus Oros

This one would drive me crazy. You’d have that one manager who would insist that they’d need more to be able to organize their work. It’s usually more fields, but sometimes it’s also more issue types, and on rare occasions, it’s weird workflow tricks.

However, all these divisions evaporate when you look at their process. The manager has put all of these artificial walls up that doesn’t exist. And if they do, they can use Labels or Components’ existing functionality to describe and sort accurately.

Look, a complicated process helps no one and makes life more challenging. The complications may have been thought up to try to make life easier, but they rarely do. This problem is why – save for infrequent circumstances – I still recommend a relatively simple workflow and project settings for most teams. What’s there already is flexible enough to organize work for most groups while still allowing it to accommodate 99.999% of situations.

# 6 –  If you don’t plan to either require it or report on it, it doesn’t need to be a custom field.

– Rodney Nissen (Coyote Creek and That Jira Guy)

This one goes under “just because you can, doesn’t mean you should.” I get it. Custom fields are nifty. They are one of the things that makes Jira unique in its niche. But you don’t always need a new custom field for everything.

Let me explain. I once had a request come in for ten new fields. They were as such:

  1. Process Details
  2. Shipping Address
  3. Cost
  4. Shipping cost
  5. Reason Needed
  6. Rack Assignment
  7. Rack Position
  8. Purpose
  9. Shipping Date
  10. Received Date

Okay. So, I can immediately tell that 1, 5, and 8 are things that can and should go into the Description of the issue. Upon asking some questions, I found out that 2, 4, 9, and 10 are not going to have reports run on them, and are not required for every issue, so they can also go into the Description when needed. So within a few minutes of thinking and some questions, we have already eliminated seven of the ten, which leaves us with Cost, Rack Assignment, and Rack Position.

Cost will be needed on every request here, as will the Rack Assignment and Position. Furthermore, they plan to run a report on the Rack Assignment field to see what work has been done on which rack (to identify problem children). Those three pass the test and had field made for them. Yes, the analysis will take some of your time, but your teams will thank you in the long run, as will your Jira instance.

# 7 – If you are creating a provision to happen once a month or one out of 100 issues, you should not be making a provision for it.

– Jesse Wisener (Coyote Creek)

This idea comes from the idea that you, as the Admin, only have so much time. If you are going to spend time on an automation, provision, workflow trick, etc., it should be on something used often enough to matter. But what is that cutoff point? When is something used often enough?

Well, either once a month or once in 100 issues seems to be the happy medium. That is often enough that it will make a noticeable difference in your user’s lives, but still justify the time you’ll spend on creating and maintaining it. Some people won’t like to hear this. But no one else will do the cost/benefits analysis for you, trust me on that.

# 8 – Start as simple as possible and only add complications to alleviate pain points.

– Jesse Wisener (Coyote Creek)

This one I’ve alluded to several times, but here it is in all its glory. You should have a good reason to add anything to your setup. Workflow, field, permissions scheme, anything. Essentially, you should always seek to deliver the simplest solution possible.

Why? Well, for one thing, it’s easier to understand. You won’t have to be spending meeting after meeting explaining the solution to team after team.

And another thing, whatever you make, you will also have to maintain. The simpler things are, the better chance you have of not having something break during an upgrade.

Also, it will lead to adoption. You rarely hear, “Yo, there’s this team that has this super complicated deal, maybe we should look into it.” More often than not, people will seek to adopt and use things that they see are easy and working from other teams.

So yeah, as my Engineering professors would hammer home, “Keep it simple.”

# 9 – Value your own time as much as you value others, and visa versa.

– Rodney Nissen (Coyote Creek and That Jira Guy)

I’ve had to learn this one the hard way. Some people won’t value your time if you don’t value it yourself. For example, I made the mistake of letting people at a company know that I can use the CSV importer to bulk-create issues. One project manager went a bit crazy with that, and at one point, send me a CSV sheet with only 17 issues. He valued his time so much and mine so little that he felt it wasn’t worth it for him to make that relatively small number of issues.

I had to push back a bit, and even get his manager involved (to which his manager said to him, “You’re joking, right?”). However, it would also be easy to take to the other extreme and refuse to do anything because your time is too valuable. That is not what I’m saying.

What I am saying is that it’s a balancing act. People will need your help with the Jira instance, but you can’t let them take all of your time. Just find a common-sense point where it’s reasonable for you to help without being pushed around.

Thanks to The Jira Guy

A big thanks to Rodney for allowing us to repost this. You can find his original “Rule of Thumbs” post on the The Jira Guy site.