Back in September, I came to my readers asking for any rules of thumb they use. And boy, did you deliver! Back then, I published eight of them in a piece that made me incredibly proud.

However, I also warned you back then that I had enough to revisit the concept. Well, here we are! To refresh your memory, we used Merriam-Webster’s definition of a Rule of Thumb:

Now I want to address the most frequent piece of feedback I got from that post. I had several people say, “I disagree with X because I don’t see that working in my circumstance.” It was never the same rule, but these people had quite lengthy arguments against whatever rule of thumb they took offense to. To this, I say, “Great!”

First of all, if these items worked 100% of the time, they’d be best practices rather than a rule of thumb. They work in most cases, but there will be exceptions. If you are the exception, I fully expect you to be able to realize this. Likewise, if you try one of these and it’s just not working for you, I also expect you to realize this and change course.  

Secondly, I love getting comments. Yes, even those that disagree with me. The Atlassian Community is generally not toxic, so I usually don’t have to worry about the vitriol and venom that are most comment sections on the Internet. And being exposed to different ideas is how we grow as Admins. So, let me know if you disagree! I’m working from one viewpoint – and while I read and study as much as I can from other experts, I’ll readily admit that I have room to grow too.

However, I think we’ve delayed long enough; let’s get into it!

“If your 500+ projects do not share a single scheme, something is definitely going wrong in your organization.” – David Friedrich (Meelogic Consulting)

As I stated in my project permissions post, one of the best ways to keep your object count low is to share schemes between multiple projects. This practice will require some diligence on you when creating a new project, but it’s the best way to keep your instance performing well in the long run. 

However, while that is at the heart of this rule of thumb, I’m not sure that’s the spirit. I believe David is saying that if you feel you have some requirement that makes it so you cannot share schemes between any project, It might be time to raise some flags about the organization’s policies and processes. After all, teams work best when there is a free flow of information into and out of various teams.  

Yes, there will be projects that will need to be walled off for Privacy or Security reasons, but in general, most projects within a business unit could share schemes and workflows. Having teams that work together speaking the same language will significantly speed things up.  

The best example I can recall is a mess I had to clean up where one team was using “Done” as their final status, and another was using “Closed.” These teams had to work together, but things were being missed because one team was waiting for an issue to be “Done,” but the other team had already “Closed” it. This situation was resolved by getting both team-leads in the same room, explaining the problem, and getting them to agree to the same workflow.  

Which one did they choose? Well, that’s between them. I’m not ready to wade into the “Done vs. Closed” argument publically – just yet. 😉

“If you don’t know how you want your project set, you don’t need a new project.” – Przemek Wysota (Deviniti)

So, just to get this out there, I don’t think this is directed at people new to Jira. Those people will need some guidance as to what options there are and how to set things up. Having several pre-configured options that you can clone from is helpful in these situations. 

No, I think this is directed at those program managers who want a third or fourth project but still can’t make up their mind as to how they want it set up – or for that matter, can’t give you a strong reason why they even want it. These are the people who will come to you weekly (or more often) with changes they want to be made.  

It’s one thing if you are new to Jira; it’s another if you are a veteran and still can’t decide how you want things set up. The last thing you’d want as an admin is to entrust a person like this with another project and potentially double the work this person generates for you.

If you can’t make your custom fields Generic, they will never get reused.

This one is from me. I’ve seen all too often where a Jira instance is cluttered with custom fields, just to find examples like “ESD Due Date” or “HR Case No.” In these examples, the ESD and QA coincide with the Project Keys where these fields were used.  

In the first example, the team lead was part of a chain of projects the issue would move through and wanted a Due Date for their team that was separate from the overall issue’s Due Date. Fair enough – but by putting the Project Key in there, you guaranteed that no one will reuse it ever. For this one, I’d probably have recommended they change it to “Internal Due Date” or “Team Due Date” – something that can be reused without much work. 

The second example is even worse because it could be reusable just by dropping the HR bit. Maybe QA could use it to track which test was used on an issue, or maybe Dev can use it to refer back to an outside ticket system. But by having HR on it, you’ve limited it to just that one use case.

That’s at the heart of this Rule of Thumb. You can’t foresee all use cases that might pop up, but by having Custom field names be as generic as possible, you can at least maximize your chances of reusing something. 

Never have two fields with the same name.

This rule is also from me. “If Jira lets me do it, why does it matter?” you may ask. Well, it goes like this.

Imagine you created this situation, and now you have to add one of these fields to a screen. If you are lucky, they are different field types, and you can identify which one is which that way. If not – well, first I’d ask, “Why?” Then I’d say good luck because, at that point, it is a complete guess that you have the correct one. 

Then your users go to write a JQL query with it. Well, again, I wish your teams good luck because this is what they’ll see. If they are good, they’ll understand how CF numbers are generated and know which is which that way – but that will be about it.  

In general, this is a bad situation and is easy enough to avoid. So unless you have an airtight reason for this, just don’t do it. 

Never Create a user named “Unassigned” or a resolution named “Unresolved.” – Matt Doar (LinkedIn)

 These go into the “Um…why?” category. For both these fields, Jira has built-in states that already account for these situations. Having them added will only confuse both users and Jira itself.  

For example, if a resolution is empty (that is to say, if it has a NULL value in the DB), then Jira will show it was Unresolved. Adding an Unresolved Status means what exactly? Jira will see it as a resolution, which means it will cross it out and show it as resolved. But by definition, it’s not resolved – thus leading to Doar’s Paradox. (Sorry, Matt, but you asked for it!)

The same goes for the Assignee field. Jira has built-in queries for issues not assigned, and having a user named “Unassigned” will lead to another such situation where Jira will think it is assigned and treat it as such.  

If your system doesn’t have a Resolution Screen to pop up, you should make one.

This one always puzzled me. In the default, vanilla Jira workflows, it assumes a resolution of “Done,” and auto sets it when an issue does its final transition. But that leaves out one of the best ways to tell the story of an issue: Its Resolution. Was this issue closed because you completed the task? Or was it closed because it was no longer relevant? Was this a duplicate of another story? Why was it closed?  

That question is precisely why the resolution field exists. So, as a standard practice on an instance, I’m working on, one of the first things I’ll do is create a new screen with the resolution field. Then I can use it in any workflow’s final transition, have it pop up, and add a validator to check that the Resolution field is set (Thanks, JMWE!). As a final step, I remove the post function that auto-sets the Resolution, and there you go! Upon closing, you have to set the Resolution to something appropriate and even have a chance to add a comment. 

While not appropriate for every team, I always prefer this approach as it gives me a way to express the story of the issue more clearly.

And that’s it for this week!

So what do you think? Do you agree or disagree with these rules? Do you have any you follow that I haven’t shared yet? Be sure to leave a comment with your thoughts!  

You can also follow me on Facebook, LinkedIn, Twitter, or Instagram! There I post sneak previews, polls, and community news. You can also use the form below to subscribe to the blog, which will deliver new posts directly to your inbox. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”