Rules of Thumb (X-post from The Jira Guy Blog)

[Rodney Nissen - ReleaseTEAM]

(Originally posted here)

The Merriam-Webster dictionary defines a Rule of Thumb as:

a) a method of procedure based on experience and common sense

b) a general principle regarded as roughly correct but not intended to be scientifically accurate

What does this have to do with Jira? A fair bit, honestly. 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! So let's dive in and see what we can learn here!

1) If your workflow takes more than 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."

Yeah, that's not going to make the 30-second mark. I doubt that it will survive a dedicated meeting. Let us not forget that this workflow would not only be impossible to communicate; it would also be a nightmare to maintain as well.  

That ultimately is what this rule of thumb is meant to protect you from. A workflow you can't explain effectively and can't maintain easily does no one any good.  

2) If your workflow has ten or more 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. Below nine, and it seems doable. So as far as rules of thumb go, this looks to hit the sweet spot.

3) If you have to scroll more than twice on a screen, it’s too long. – Logan Hawkes (Coyote Creek)

This one also goes into the same category. I touched on this previously with my "Jira Sucks" article a few weeks back. 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 and fast 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 more than 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 is there is already 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)

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)

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.  

And that's it for this week!

This post is nowhere near an exhaustive list, so I can see this being a recurring segment we return to every so often. I want to thank Logan Hawkes for both the original idea and some of the first rules to include. I just loved this idea for a post that I had to do it as soon as possible. I also want to thank everyone in the community who helped out so much in this. I knew the number of Rules I wanted, and I wasn't coming up with enough on my own.  

Don't forget, if you've enjoyed this post, subscribe to thejiraguy.com to receive new posts directly to your inbox. You can also find me on Twitter, Facebook, and LinkedIn, where I'll post updates from the blog, news from the community, as well as the occasional plea for help on future articles! But until next time, my name is Rodney asking, "Have you updated your Jira issues today?"