Is Jira feeling slow lately?

Well, last week. Where do I begin? Maybe here:

Yeah, pretty good, right? I thought so too, then Thursday happened:

Just Wow. Thank you, guys! I keep finding that just when I see the ceiling for this community, you guys go and surprise me like this.

On top of the page views last week, I also had a number of you reach out to me last week for various reasons. However, one drew my attention in particular.

Well, Harsha, it’s been a while since I released a System focused post, so challenge accepted. Fair warning, though – this topic gets intense. Jira is a rather complicated system. Even if we ignore the configuration and focus on the system, there are still many places we need to check out to know what bottleneck is causing Jira to perform slowly. But too late, you’ve already asked for it, so let’s dive in.

Lag Sources


Well, this should have been obvious as the first place to look. If your CPU is overloaded, it’s going to impact performance for the end-user. It amazes me how many people skip looking at this and head directly to adding more Heap Memory to the JVM (which we’ll talk about in a moment). If you are on a Windows Server, you will likely know how to check CPU on it via the Task Manager’s Performance Tab.

This utility will also give you information on Disk Throughput, Memory usage, and Network utilization – all good indicators if you are trying to diagnose slowness in your Jira instance. However, on Linux, I prefer to use the top utility.

This tool will tell you many of the same things, but it requires some know-how to interpret. So why use top instead of something like glances or htop? Well, it’s because top is an almost universal tool on Linux systems. It is so rare that I encounter a system without it that I cannot actually remember it. So how do we interpret this data?

The first thing I usually look at is the load average. This measurement is broken down to load over the past 1 minute, 5 minutes, and 15 minutes. Ideally, this number should not get over 80% of the number of CPUs you have. Do you have 4 CPUs? That number shouldn’t be above 3.2, for example. It’s not an exact science, but it’s close enough to work as a rule of thumb.

Another place we can look at is the CPU Utilization, underlined above. These numbers are broken down into various categories, as shown below.

us: user cpu time (or) % CPU time spent in user space
sy: system cpu time (or) % CPU time spent in kernel space
ni: user nice cpu time (or) % CPU time spent on low priority processes
id: idle cpu time (or) % CPU time spent idle
wa: io wait cpu time (or) % CPU time spent in wait (on disk)
hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts
si: software irq (or) % CPU time spent servicing/handling software interrupts
st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine

The two we are most interested in is “us” – this will be the active Jira Processes, and “wa” – this will alert us to a slow disk problem. These measurements are broken down as a percentage of the total CPU capability of the system – so they all should add up to 100%. So if your us measurement is taking 80% or more of the total system usage, you are using too much CPU.

So, the answer is just adding CPUs, correct? The answer here is maybe. If you are on a VM, it might hurt more than help. How so? My understanding here is that the Hypervisor (that is the VM Server) will only schedule a given cycle for the VM if it has enough CPUs free for that cycle. Therefore, the more CPUs are allocated to the VM, the more the Hypervisor has to free up, and the more time between cycles on your VM. How much is the max for your Hypervisor? I cannot say, but your Hypervisor Admin should tell based on the VM Host’s CPU Utilization.

What if the wa value is high instead? This event is a sign that your disk speed may be limiting your system performance, at which point we’ll need to look at your disk speed – which we’ll discuss below.

Heap memory

So let me say – Atlassian already has an excellent video freely available on this. It’s called “Trash Talk! How to reduce Downtime by turning Garbage Collection,” and I still reference it to this day. Seriously give it a watch.

Oh – you’re still here. Well, this is awkward. I thought everyone would have gone off to watch the video. Seriously, I was at that talk at Summit 2016, and I still refer to this video as a refresher. If you are a Jira System Administrator, you oh it to yourself, your users, and your career to learn how to tune the JVM. 

So what are the take-aways from the video? First, don’t try to change the GC Method or any of the GC Parameters. Atlassian sets these to settings that will work for 99.9% of cases. I usually only touch them if asked to by Atlassian support. No – what I typically tune is just these two numbers.

As a best practice, I like to set them equal, that way the JVM will reserve it’s max amount of memory on startup. This way I won’t be surprised in a day or two by an out-of-memory error (or worse yet, the system deciding to just kill the JVM process.)

The second takeaway is that it is entirely possible to cause performance problems by setting the Heap Memory too high. Doing so can cause one of two issues. In the first problem, you end up choking out legitimate system processes from Memory, slowing down the whole System by forcing it to use SWAP space. In the second, the JVM wait’s longer to do a Garbage Collection, which means that GC Cycle will is more likely to be a full GC where the System has to pause the JVM. If the JVM is paused, it is not serving Jira Pages…hence the lag.

So, how do we know what number to set it too? We have to run it for a while, then analyze the GC Logs to find that out. If we see that the JVM is doing Garbage Collections too frequently, we need to bump it up. If we see that the GC’s are pausing the JVM, we might look at bumping it down a bit. Unfortunately, there is no hard-and-fast rule that says, “If you have this many users, set it to this.”

Fileshare/Disk Speed

Now you know the CPU isn’t overloaded, and the JVM is tuned correctly, but your System is still slow. Where do you look next? Well, the file system. I alluded to this previously, but you can get a clue if your System is having some Disk Access issues by looking at the wa statistic in top. However, while that will help if it’s high, it can give a false negative.  

The Good news here is that Atlassian gives us a guide on how to run a Disk Access Speed Test.

Basically, this will have you download a jar file from Atlassian Support, and run it against the location where Jira’s Index resides. Should look something like this:

java<Jira Home Directory>/caches/indexesV1 -jar support-tools.jar

If you run this, you should get a table like the one above. I typically look to the Median and Max columns, and compare against the table Atlassian provides (copied below).

Open< 40,00040,000 – 150,000> 150,000
Read/Write< 40,00040,000 – 100,000> 100,000
Close< 20,00020,000 – 100,000> 100,000
Delete< 50,00050,000 – 300,000> 300,000

As we can see from my results, the medians are either in the OK or Excellent Range. However, my Max times are not (Also, OUCH on the Open Max). This result was likely an outlier caused by a problem on the VM Host, but cannot be ignored outright. If this were an enterprise setup, I’d start asking the VMware Admin questions to figure out if there are any problems with the storage and if we can speed it up at all.

My result is because I am running on seven-year-old hardware disposed of by some company as end-of-life and cobbled together by someone who is still learning.  


So, this will be a radical idea, but sometimes Jira’s slowness isn’t caused by Jira. Sometimes it’s caused by an external system. No, seriously, how well your Database performs will have a MASSIVE impact on how well Jira performs.  

Atlassian thankfully also has a tool for this situation.

Again, this will have you download a jar and run it on your Jira server.

java -cp PATH_TO_THE/atlassian-log-analysis-0.1.1.jar:PATH_TO_YOUR_JDBC_DRIVER_JAR \
com.atlassian.util.benchmark.JIRASQLPerformance \
> db-perf-test.txt

You will get the YOUR_DB_USERNAME, YOUR_DB_PASSWORD, JDBC_CONNECTION_STRING, JDBC_DRIVER_CLASS settings from your Jira instance’s dbconfig.xml file. A note on this tool: you need 1000 issues in your Jira instance to run it, as I found out the hard way.

However, Atlassian does give you an example of what the output should look like.

----    ----    ----    ----    ----
stat    mean    median  min max
----    ----    ----    ----    ----
retrieve-issue  5,338,000   979,000 213,000 46,007,000
get-issue   174,775 93,000  62,000  11,621,000
retrieve-workflow   5,117,153   607,000 341,000 47,738,000
get-workflow    98,996  64,000  40,000  2,962,000
retrieve-custom-field-value 601,093 495,000 316,000 23,082,000
get-custom-field-value  91,246  52,000  37,000  3,453,000
----    ----    ----    ----    ----
All times are in nanoseconds.

Atlassian states they don’t have an “Excellent, Good, Bad” chart for DB Values clearly defined, but they tend to look for any values below 20ms as good, and 10 ms as Ideal. (Remember, 1ms = 1,000,000 nanoseconds).


Well, it’s not the CPU, it’s not the Memory, File System, or Database. What does that leave? Well, the network can be a bottleneck. You can usually check this with a simple ping test. Does the ping take a long time to reach the Server? Then you are more likely to see issues with Jira’s speed.

Look, I get it. You might be in India, and your company’s Server is located in the United States. You are only ever going to get your pings so low. If you are on Data Center, you can use a CDN to help with some of that latency, but it will take actual time for the packets to travel around the world. 

However, if you are located in the same building as your Jira Server and are still getting high pings, it might be time to talk with your Network Admins to figure out what is going on – especially if you’ve run all the test to say it’s not the Jira Server itself. 

Maybe it’s just busy.

Look, I’ve done my best to ignore the Jira Configuration in all this and focus solely on the System. However, you will get to a point where it will become impractical to add more Memory or CPUs to a server. At that point, you have two real options.  

For your first option, You can do the hard work and clean up your configuration. Get rid of unused workflows and permissions schemes, consolidate duplicate custom fields, and get Jira healthy in that regard. It’s not easy, and may not be politically expedient, but it is well worth it.

Your other option is to migrate to a Data Center Architecture. Look – there are only so many users a single server can handle. Data Center Edition solves this by spreading the load out to several servers, each working together to form a single Jira instance. I have several articles already on how to convert your Jira server instance into a Data Center instance. So if this sounds like you, maybe it’s time to consider an upgrade. 

Well, there you go!

Look, this is an involved topic. Pinpointing your performance issue to a single cause is tough – especially when it’s a real possibility that there are several causes. But it’s well worth it to go through each of these and see how your System is doing. 

This week has been a busy one. I haven’t had a chance to read as much or do research like I usually like to do. So, I only have one webinar to share with everyone this week. “Get Jira superpowers: Reporting on Projects and Calculated Fields” is a joint presentation by Deiser, Old Street Solutions, and cPrime. And it’s tomorrow, 11:00 AM Eastern time! You should check it out!

As always, if you enjoyed this post you can subscribe below to receive new blog posts directly to your inbox. You can also like, follow, and comment on social media to help your colleagues discover our content! You can find me on TwitterFacebook, and LinkedIn with regular updates, new posts, and news about the blog. But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”

Rules of Thumb

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

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! 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 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 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.

Basically, your backlog grooming meetings looks like this…

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)

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.  

I loved the response to the various links I posted last week, so I figured I’d keep that up for this week. First up is a webinar/ACE virtual event, “The things that should NOT go in your Jira.”  Matt Doar, Toolsmith at LinkedIn, will give this presentation on Oct 2. It’s a bit early in the day for the U.S., but it should still be well worth it to listen. 

The second link I thought was interesting was an article titled, “Archiving Jira issues helped this government agency comply with privacy rules and keep Jira clean.” Yeah, it’s a mouthful, but I thought the topic was interesting. It is a reasonably good look at how they set up the system to archive issues when triggered.  

Don’t forget, if you’ve enjoyed this post, subscribe below to receive new posts directly to your inbox. Be sure to Like, follow, and comment on TwitterFacebook, 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?”

Jira Blunders!

Last week I got a call from my family. Trust me; this does have something to do with Jira. My Mom told me that my younger brother of 17 was having problems with his Chemistry homework, and she wanted me to go over it with him. Being 17, he protested saying he didn’t need my help because he “had used a calculator.”

When I put my foot down and brought him into a Zoom meeting, I found that he had used an incorrect formula. This situation meant that while his math work was right, the answer was still wrong. I sat him down and explained his error to him, to which he stated he had hurriedly copied down the formula wrong at the end of a class.

I then asked him, “What did you learn?” He replied he needed to double-check his formulas. So what does this have to do with Jira?

We all make mistakes. It’s both very human and part of the learning process. However, not taking away a lesson on it is just a waste, which I was trying to impress on my little brother. The same goes for Jira. There will be blunders. This week, I am reviewing some blunders both I and colleagues have made to get a chuckle and help teach some important lessons.

Always Double-check system commands

So this didn’t happen to Jira – but it just as easily could have. I was working on a Perforce upgrade on a system. As part of this upgrade, I needed to upload a new directory to the server, then change its permissions. This server was a Linux-based system, so I was working on the command line as per my habit. 

So I uploaded the directory and its files, and then I went to change the permissions so that the perforce user could access those files. This is where disaster struck.  

This was the command I meant to run:

chown -R perforce:perforce ./

And this was the command I ran:

chown -R perforce:perforce /

Catch that change? One tiny little dot missing. For those who may not know, a “./” in Linux is shorthand for, “The folder I am currently in.” However, “/” , when paired with a -R, is shorthand for “Every file on the system.” This slight error meant that every single file on the system now belonged to the perforce user. But it gets worse. So, so much worse.

This exercise took place during work hours and was meant to stage some files ahead of a weekend upgrade on Production. Which meant I had just made a catastrophic error, on Production, in the middle of the workday.

I eventually realized my mistake when the change command took much longer to process than it should have. Even then, I’m embarrassed to say it had processed a fair bit of the filesystem before I realized my mistake. So, damage control mode. I changed most of the filesystem back to root ownership, save for the processes and files I knew to be managed by other users. Somehow I had it all back to normal relatively quickly. The miracle is that no one attempted a push to Perforce during all this, so my mistake went otherwise unnoticed.

So, what lesson did I take away from this? Well, if I am on Production, I do not free-hand commands. I write them out ahead of time, then copy & paste them into the terminal while working. Even if it’s a minor task, Production is sacred ground – treat it as such.

Label Your instances Carefully

This one was another mistake of mine that took place in the middle of the day. We were having some problems with our Jira system, so I was engaging with Atlassian Support to see if we could resolve them. Atlassian had helped us identify a possible culprit, but we needed to test changes in a Development environment before pushing changes to Production per our policies.  

However, our change controls for Development was – how do I put this – non-existent. Which meant I was free to go into Dev and make these changes whenever. So I decided the 11:30 AM on a Tuesday was a perfect time!

Now, when I’m a Windows PC, and I need to connect to a Linux Server, I’ll use mRemoteNG. It’s just a handy tool to manage all your system connections and work with individual systems as needed. However, this is how I had labeled and set up my connections at the time.

Can you see where this is going? Yep. I connected to “Dev” and started making my changes. I double-checked all the changes against Atlassian’s ticket, and once I was happy, I restarted Jira. Then I started getting questions.

“Hey, is Jira down?” “What happened to Jira?” “Is Jira down for you too?”

With a cold sweat, I looked over to my connection and realized my mistake. I had just made these changes to – and restarted – Production. And given our hardware at the time, Jira would be down for another two or so minutes.  

If there is something I do well, it’s handling downtime. I let my team know what had happened, and that Jira was coming back up. Yes, embarrassing, but I would have time to be embarrassed later. They ran interference for me while I did the last few steps to bring Jira back up and running. Crisis averted.  

So what did I learn? That day I learned that I needed to do a better job of labeling Production and Development systems. I also needed to put safeguards to ensure that I realize that I’m connecting to Production. After that day, this is how I started organizing these systems. 

I also removed the stored password from the Production systems so that I would have to enter it every time I connected to these servers. This process would serve as an extra layer of “Something is not right here,” which would hopefully prevent me from making that mistake again. And well, so far, it’s worked!

Oh, and if you were wondering, the new settings did fix our Jira problems, so there’s that happy ending.

Leaving your email on while Load Testing

This one came from a colleague at work. I’ll often ask for input or bounce ideas off my fellow East Coast consultants at Coyote Creek. This entire article started as one of their ideas!  

Anyways, one of my friends was doing some load testing on Jira for a client. He had just cloned their Production system to create a Development environment; that way, he could do his testing without impacting users. All per best practices, so nothing wrong there.

So he then turned on JMeter and started creating hundreds of issues on Jira. However, when he cloned Production, he had forgotten to turn off outgoing email, which meant that now users were getting flooded with emails. When they’d go to find these issues in Jira, they’d not exist. Word eventually filters back to him, and he shuts down the test.

So, what could we learn from this blunder? That’s simple. It is considered best practice to turn off email on any Development system you have. Don’t get me wrong; there will be times you need to test things related to email. When this happens, I turn email back on only long enough to run my test, then turn it immediately back off. It’s just not worth the user’s confusion.

And that’s it for this week!

What blunders have you made with your Jira instance? Have you any lessons learned you’d want to share? Then be sure to leave a comment on this post, and I might include it in a follow-up! And if you enjoyed this post, subscribe below to get new articles delivered right to your inbox!  You can also follow the blog on Facebook, LinkedIn, and Twitter to get the latest from us.

There are a few things I want to call your attention to this week. I want to start featuring interesting posts, webinars, or webpages I run across – and I have a few to share this week!

Let’s start with this blog post from Notes From Kris, which explains the various resources you have access to from Atlassian. Having all of these in one place is handy – especially if you are new to the Atlassian Ecosystem.

The next is a fun JQL quiz from Elements, which is an Atlassian Marketplace partner. I haven’t used any of their apps before, but they are definitely on my radar now. The JQL quiz was rather fun, but also very challenging. Give it a try and let me know what score you get!

And lastly, a webinar from Atlassian on “How to become an Atlassian Community Leader.” On top of my current goal to become an Atlassian Certified Master, I am also working towards a Community Leader status, so I plan on attending this webinar.

I hope you found something useful in this section. If you have, let me know, and I’ll keep including exciting things I see here! But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”

Book Review: 7 (non-user’s) stories on (not only) Jira governance

Governance. If you are like me, this brings to mind long, boring meetings where you, as the admin, try to seek approval for some change, only to have the discussion quickly off the rails to something not even related to Jira. No, just me?  

I have long stood on the fact that I don’t know everything Jira. As much as I’m teaching others through this blog, I am still learning myself. And knowing my efforts at Jira governance have been less than successful, I was excited to see a new book on the way. I was even more excited to be offered a copy of “7 (non-user’s) stories on (not only) Jira governance” by P.J. Wysota to review! So, let’s take a look together with the first Book review of the blog!

As a note here, I did receive this book free of charge. Honestly, I was planning on reviewing the book even if I had to pay for it, so I don’t think I’ve let the fact it was given to me sway my opinion too much. But if that matters to you, now you know.


This book takes a rather holistic approach to the idea of Governance. Which is to say, it starts you out with some of the basics. As such, the first chapter’s theme was “Governance’s ‘Zen’ – keep balance.” Here, P.J. goes into detail about the balancing act that is being a Jira Admin, or “Solution Architect” as he prefers. And he nails it. The art of being a good Jira Admin is balancing competing interests. Your users want a fast, responsive system, but they also want every custom field and workflow under the sun.  

Another Story in the book that we had a lively discussion about on Twitter (especially after last week’s post) was about Getting the right people. While we don’t agree on terminology, I should point out that we at least agree on principle here. He prefers the idea of a “Solution Architect” – someone technically savvy enough to understand and manage the system, while being aware of how people are using Jira and what the teams need Jira to be. This person should be the core of a larger group of Jira Admins and a Sysadmin. While I’m not opposed to this idea – such people are at a premium in the workforce, so I’d instead work on building that competency yourself rather than finding someone to fill that role immediately. 

One of the stories I loved in this book centered around the concept of Strategic choices. I love this chapter because part of it argues, “Why and when not to use the Atlassian Stack.” It reminds me of something I heard a comedian say one time that stuck with me. This comedian said his father would often say, “If you can’t think of a counterpoint to your opinion… you’re not entitled to that opinion.” Or as P.J. put it:

And if you are to successfully govern Atlassian applications, pardon my French, but you need to strip off whole marketing bull***t of Atlassian, know pros and cons of your applications thoroughly, and be able to map any potential showstoppers in “Atlassian transformation” plan.

P.J. Wysota, 7 (non-user’s) stories on (not only) Jira governance

We, as Jira Admins, should know where all the pitfalls are. We should be able to go, “This tool may not be the best fit for this process.” However, P.J. goes into some detail about situations he’s been in where the answer wasn’t an Atlassian solution. And he raises a valid point here. If we aren’t empowered to say “Look, Jira’s great, but it’s not a good fit here.”, Jira will quickly get a reputation as a half baked solution.  

The Last Story in the book deals with the Atlassian Marketplace. This topic brought this blog to P.J.’s attention because it’s a topic I also covered recently in my “Jira Sucks” post. We both talk about this idea that some users have that Atlassian should put more core functionality into the product and lean less on the marketplace to fill these needs. 

We both approach the topic from different directions but arrive at the same conclusion – That Atlassian puts what they feel is needed by the majority of teams in their tools, and that any further needs can be met to fill those niche requirements. While the functionality may feel significant to you, they aren’t needed in a Project and Task management tool in the grand worldwide view.

And look – I just covered four of the Stories here. There are seven stories in total, and I took something I could apply to my practice from each one. When you have an infinitely configurable tool like Jira, finding a standard set of best practices is difficult. What works for one team may not apply to others. It’s up to you to figure out your teams’ needs and match up the specific capabilities to those needs. And that is the primary take away from the book. Governance isn’t about rules or processes, though they require those things. Governance is about figuring out the right setup for your organization in an inclusive way and requires you to build it into your processes from the ground up. 

Areas of Improvement

When I review Apps, I make it a point not to shy away from the bad points. If I can think of a way they can improve, I include it. And every App can be improved. I think the same should go for books. While I still wholly recommend the book, I feel I’d be amiss to my responsibility if I exclude this section. So, here we go.

I hesitate to bring this point up, though. As any long time readers can attest, I’ve always had my own struggles with editing. However, there are a few passages in the book I found myself reading a time or two to understand fully. They were always minor spelling, tense, or grammar mistakes – and trust me, I’ve published similar mistakes too – but it did interrupt my flow while reading.  

However, that was it. The ideas in the book were sound and well explained. I can see myself referring back to this book repeatedly to refresh myself on concepts as different situations come up. And I feel that is the real test of a book like this. It’s one thing to read it and understand the concepts. It’s another altogether to go back to it to apply those concepts at the appropriate time. And I feel this book hits that mark well.  

Would I recommend this book?

Yes, absolutely! As I started this piece saying, Governance is something I’ve always struggled with. And from what I’ve seen, I’m not alone. However, P.J. does a great job of breaking it down to reasonable Stories to apply to your Jira Administration practice. So if you can, take the time to read this book. You won’t regret it. 

However, that will be it for this week. If you’ve enjoyed this book review, don’t forget to like, share, and comment on it! I always enjoy reading your feedback! You can always find me on LinkedInFacebook, or Twitter, where I post the latest from the blog. If you’d like to get new posts automatically delivered to your email, don’t forget to subscribe below! But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

The Jira Dream Team.

So, I know I had said I’d have a book review this week. Unfortunately, it’s not ready. It’s like I’ve spoken to software teams forever now: A Bad product released on time is far more memorable than a Good product delayed. I want to make sure the review is worthy of the effort P.J. put into writing it. So, a delay is in order.

The second reason for the change is something I noticed late last week. This past Monday was the anniversary of the first post that went big. I had a few posts previously on here, but they weren’t consistent. Honestly, I was re-posting stuff I’ve done for work. But my post on using Jira for a job search – that had some legs and inspired me to start posting regularly. Seeing as that post was about me trying to get hired, I’ll take the opposite approach. I’ll look at who I would hire if I could build my perfect Atlassian team within a business. So, lets get started on this.

What Everyone Needs

We’ll start with the roles that every Atlassian team will need, whether they are supporting a software team, IT Team, or just general business teams. I fully realize that you’ll need additional people depending on your situation, but this is a good starting point. So let’s hop into it!

Team Lead/Product Manager

Every good team starts with a guy who can chart the path. I see this role as someone who will look ahead of where the team is going and remove roadblocks before the team arrives.  

Of course, to see these roadblocks, this person needs to be more than a little familiar with the tools and setup, which means it would help if this person were a former Systems or Jira guy themselves. Additionally, this role will need to interface with many people, so you don’t want someone here who isn’t good at managing these interactions.   

Ultimately, this person’s job is to look at everything that needs to be done and set the priorities. To do so successfully, they’ll need to balance a lot of different interests. They’ll need to take input from the team, stakeholders, vendors, and their research and experience, and make some tough decisions. These decisions won’t always make people happy, so they’ll also need some good conflict resolution skills. However, if you can get a superstar in this role, things will always seem to work out well for the team.

The Systems Guy

If I’m honest with myself, this is me. This role will ultimately be responsible for the backend health of Jira and Confluence. So, let’s talk about them.

This role should be familiar with running Java applications on the Server OS of your choice. Honestly, I learned to do this by running a Minecraft Server. Just saying, this isn’t the most challenging box to tick.

They should also be aware of how different front end changes can impact performance. This role will likely be your technical lead, so they’ll be expected to advise and review changes some of the other roles are making. 

Something you also want to look at is who will cover for who during PTO. In this case, the System Guy should be able to cover for the Team Lead or either of the Jira/Confluence guys should they need to take off. Ideally, I see the career progression here being Jira Guy -> Systems Guy -> Team Lead. This means that this role should be starting to develop those essential leadership skills. They aren’t ready to fly the plane solo, but they are definitely on their way there and can take over for short hops. 

The Jira & Confluence Guys

 This role manages Jira’s front end. While that is a simple statement, this will require a fair bit of specialized knowledge. This person will create and manage fields, work on workflows, and do all of the necessary things to configure Jira for the users. In fact, there should be enough work here to justify two of these people in any large organization.

In my mind, these people should be developing the necessary skills to start working on the system side. Ideally, they should be able to help out should the System Guy have to be out, but I wouldn’t expect them to be doing installs and upgrades solo just yet.  

This role will also be interfacing with end-users quite a bit – whether it’s capturing requirements for a proposed change or solving a user’s problems. So you’ll want someone good at asking “the right questions” to understand what’s going on. I’ve seen it time after time – what the user says they want and what they need is nowhere near the same. As the “expert,” it’s up to this role to guide users to what they need.

Customizing for your Org

So above are the people I’d say you need at the minimum. However, depending on what your organization is going, you might need some additional expertise. That’s where this section comes in. You might not need these people – but if you do, here they are.

The Developer

If I’m honest, I almost put this as an essential role. I’ve had one on the team before, and it’s incredible. Jira’s great about extensibility, but you won’t always find what you need in the Marketplace. That’s where having someone on staff who can write plugins to be a fantastic asset. 

This person should be familiar with the Atlassian SDK, as well as Java in general. Remember, though – once you go down this path, you will need to update these plugins with every upgrade. Custom plugins can also be a nightmare to deal with if you plan to migrate to the Atlassian Cloud in the future. For these reasons, I don’t ever recommend you go crazy with the custom plugins, and always look for Marketplace solutions first. 

This person can also take point on any Groovy scripts you use with Scriptrunner. This method is another excellent option to extend your Jira instance’s functionality without writing your plugins. It will still need updates now and again with upgrades, but it won’t be as bad as having a custom plugin to support. 

The Build Guy

So, you’d likely only find this in Software or DevOps organizations. However, if you are using Bitbucket and Bamboo, you’ll need one or two people to manage your build processes and systems. These should be people who are familiar with Build and Deployment pipelines and how to compile and deploy with your toolset. 

Honestly, this is one of my weaker points as an Atlassian Expert. I understand the basic concepts, but to scale it up to Enterprise level makes my head spin. However, I’ve been fortunate enough to work with some real superstars in this area who can even team a pleb like me something useful. 

This role won’t be needed for every deployment. For example, if you are only supporting IT and General business teams, there won’t be a need. However, I did want to mention it as if you need to support this kind of function; having a dedicated person is invaluable.


So – this won’t be a part of your team. But if your organization has a dedicated helpdesk team, it would behoove you to empower them to help end-users with simple problems. That is, give them the access and documentation to update permissions and other problems users are likely to contact them for. That way, they can handle the day to day and let you focus on the larger, more complex tasks.  

The Helpdesk is also an excellent place to look for up-and-coming talent. Someone who takes som initiative and learns the Atlassian platform more might be a candidate should you need another Jira guy. It also lets them acquire the skills they need to better work with users to get the information they need to solve problems. 

And there you have it. The Jira Guy’s Dream team!

Honestly, in most organizations, I’ve performed multiple of these roles. But with the team I described, you should be able to handle almost anything that comes at you. But what do you think? Is there a role you consider essential that I missed?  

As always, don’t forget to like, comment, and share if you’ve enjoyed this content. You can find me on TwitterFacebook, or LinkedIn to get the latest news from the blog. Please subscribe below to get new posts delivered every Wednesday to your mailbox if you have really enjoyed the post. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”