Jira Sucks, but it doesn’t have to

I’m betting you didn’t expect this title this week. Two things inspired this article. First, was this entry into the blog’s search performance.

This graph tells me that Google is returning my site when people are searching, “Jira sucks.” What’s more, people are clicking on the link. Not often, but still!  

The second event that inspired this post is another post someone did on LinkedIn explaining why they feel Jira is simply the worst. The odd thing is, every point they brought up is something a good Jira Admin can fix.  So I figured I’d look at why using Jira can be a terrible experience and how you can fix it for your users.

Also, a bit of a confession: usually, I like to have these articles ready by Tuesday before publishing AT THE LATEST. However, by that time, I didn’t have enough talking points to make a full article. So I had to go to social media to get feedback from the broader community! Thankfully you all gave me enough to round out the post. So, let’s get into the first of Jira’s sins.

“Jira makes it challenging to create an issue.”

I’ve seen this on almost every new instance I’ve worked on as a new Admin. The issue creation process is so arduous that most workers would rather not deal with it entirely. This experience often leads to the feeling that Jira as a whole sucks, because people don’t understand that that experience is unique to their instance. Let’s go into three factors that can lead to this experience, and what you can do about it.

Required Fields

This item is usually the biggest offender. For one reason or another, you will have a large number of required fields, which may be spread out between several tabs on the Issue Creation Screen. This format makes it so that your users have to play “Hide and Go Seek” with these required fields, click save, realize they missed one, and repeat. I’m hoping you can see how this can be frustrating to users.

I take two approaches to combat this. First, I limit the number of required fields. I do this by being diligent in asking “Why?” every time a project lead asks me to make a field required. I make sure their reasoning is sound, and that they intend to use it in some meaningful way. I also educate them about the fact that if they have too many required fields, people are going to put in junk information to get past the screen, making whatever report or information they derive from it useless. 

The second approach here is to put all the required fields front and center. That is, I put them all on the first tab, right at the very top. That way, users can tell what fields they need to fill out right away and get on with their lives. It just leads to a cleaner look overall, so it’s something I always recommend.

Too Many Fields

This one also causes a ton of headaches. People see they can customize their Jira with custom fields, and go a bit crazy. Doing so leads to a bloated, unfriendly look to Jira.  

I mean, imagine it. You are a user, and all you are trying to do is create a task to track some work you are doing. However, when you click “Create,” you are hit with a wall of empty fields to fill out. What’s your likely response? To fill it out, or say, “Eff this!” and do the work without the Jira issue?  

So, how do we combat this? Well, we always have to be diligent when creating new fields. Again, I remind you that the question “Why?” is your best friend. Find out the reason the project leads need a field. Do they want to use that information in a Dashboard? Or is it something they will need to help prioritize work? Or is it some vanity information that can live just as well in the issue description? Don’t be afraid to say “No” if the answer to that last question is “Yes.” Not only will this help with Jira’s appearance, but it will help your instance run smoother!

Secondly, we can organize the fields that we do have. Maybe only specific teams will need any subset of fields. Then we should set up tabs on the screens, which each tab representing each team. Or perhaps you only need a particular set of fields when you go to a specific status. You can have them pop up when a user transitions the issue into that status, so they don’t bloat the creation screen. The point is you have tools to organize fields, use them!

I can’t find my work in Jira.

This reason is another one I see a lot. People who aren’t familiar with Jira may find it hard to figure out how it’s organized, or where their work even is. That will lead to the opinion Jira is just too complicated and bloated. So how do we combat this?

Well, first things first – we have to talk about your system dashboard. This feature will be people’s first experience with Jira after logging in. So you will want to make sure it’s a welcoming one. Customize the introduction gadget to point to your documentation (we’ll get to that in a moment). Be sure that the “Assigned to Me” gadget is in place. However, if a user is genuinely new, they won’t have any issues assigned to them, so keep that in mind when designing your System Dashboard.  

Back to the documentation, you’ll want that in place. Jira hides its search functionality in a dropdown. Be sure people can readily find the documents to help them learn to use it. Searching issue data is Jira’s superpower, so you want to get people up to speed with that quickly. Also have documents about setting up dashboards available, and make sure people know they can create a custom dashboard to help them find their work.

And finally: workshops. As a Jira Admin, I try to hold regular seminars on JQL, creating Dashboards, tips and tricks with queries, and best practices. Some of these workshops I turned into the early posts on this blog! Be an active part of training your userbase in Jira. It will help combat the feeling that people can’t find their work.

I always have to buy an add-on to do simple tasks!

Oh boy. This one is a big complaint. And I get it: Apps are expensive. I’ve had to explain to more than a few Atlassian Partners that when I do a review, I have to get a trial license because I can’t afford to be buying (or renewing) an App a week. And if they restrict their trial license, that means I can’t do a full review.

Unfortunately, this one comes down to economics. How many employees do you think Atlassian has? The number will surprise you considering how big they are in the market, but the most recent figure I can find put them at around 3600 employees. And that’s everybody, from Custodial on up to the Founders.  

Let’s be generous and say a quarter of that number are software engineers. I have no backing for that number, but it’s an assumption, so bear with me. That means that 900 Developers are working on everything Atlassian has. Trello, Bitbucket, Confluence, everything. I counted about 20 different products offered from about the timeframe we are looking at. That means we have an average of 45 Developers per project. Now, I admit some products will have more developers than others. That’s not my point.

My point in all this is that there are only so many person-hours that can be put into features. As much as Jira wants to be the be-everything-do-everything, that takes time that they simply don’t have. So, what do you do? 

Their solution to this problem is well tested. Create an API that others can use, and allow an Add-on economy to develop. That way, Atlassian can focus on features that a larger group of people can use, and let App Partners develop more niche solutions. However, these Partners need to be able to feed their families. Some have whole businesses to support, which is why they tend to charge what they do. 

Jira sends to many emails!

My god, does Jira send out some emails! I’m sure every Jira Admin can sympathize with their users on this one. This one is objectively fact-worthy. 

The first thing I do here with a user like this is commiserate with them. I let them know that I interact with multiple projects each day, so I’ll get even more emails than they do from Jira. Acknowledge that they have a legit complaint.

Then I share with them how I manage it. I let them know how I go through, find all the issues I’m “watching,” and I unwatch any that are no longer relevant. This “fix” won’t help with current issues spamming you, but it does make a dent. I also show them how I sort Jira issues in Outlook so that I don’t miss anything critical, but am not bothered by an email every day.  

And finally, I let them know there is hope. Atlassian has announced during their last Summit that they will be implementing a feature to send out an email Digest of several updates, rather than a single email with each update. I cannot tell you how much I want this feature right now. This tidbit was honestly one of the happiest pieces of news from Summit.

And that’s it for this week!

Look, the point is your user’s experience – and thus, their outlook on Jira – is entirely in your hands. Always keep in mind that people use your system. Whenever you implement something, the question should be, “How will it impact the users?”

Honestly, I still have enough points for a followup article! You guys helped out a lot. But as I stated, I’m already running late enough on this post, so I think I’ll call it here. If you enjoyed this article, be sure to sign up below to get new posts delivered directly to your inbox! You can also follow me on Twitter, Facebook, and LinkedIn to get the latest news from the blog! Don’t forget to like, comment, and share the posts with your friends! But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”

Seven JIRA Gotchas

So, let me start with the fact it’s good to be back on a normal schedule. I love writing for you guys, but last week reminded me why I only do so once a week. But…worth it. I heard from so many of you about how much you appreciated the recap. Also – this happened.

Yeah – we got noticed!

So between your enthusiasm, likes and comments on LinkedIn and Twitter, Atlassian’s tweet, and word of mouth spreading, we have overtwo-thirds many views in the first week of April than we had in the entire month of March.

Today’s topic was actually recommended by a team-mate and colleague at Coyote Creek, Olena McMurtrey. The thought is, what are the gotchas you need to look out for when doing various tasks. I’ve outlined seven that even after all my years, I’ll still occasionally trip over. Where possible, I’ll explain how to prevent falling into the traps, and how to fix it if you’ve already fell for them.

1. Internal Directory User Required

So, your IT organization is making some changes to Active Directory, and this will require you to adjust some settings. You go into JIRA with your System Administrator account, navigate to User Directories, and find….

There are no options to edit the AD Directory (or LDAP in my case…still). This is because you have just fallen for our first Gotcha. JIRA does not allow you to modify a directory if the account you are logged in with is a part of that directory. This is to prevent a situation where you modify a directory and manage to lock yourself and your entire company out of JIRA.

For this reason it is often considered best practice to maintain at least one system administrator level account within the JIRA Internal Directory – and to use that when making these changes.

So lets say you didn’t do that. Well, it’s an easy enough fix. Go to User management > Users, then click “Create User” in the upper-right hand corner.

From here, create yourself a user within the JIRA internal Directory, then add it to the jira-administrators group to give it permissions. Log into this account and use that to change the settings.

2. Did you update the field context?

So, you have a team request a new field. Looking into JIRA, you see that field already exists on another project in your instance. Sweet! Less work for you, right? You just slap that bad boy onto the requesting team’s screens and call it a day…

That is until you get an email saying that field is still not showing up for them. You have just fallen for our second gotcha. All fields have a Field Context that you can use to limit what projects that field is allowed to be used on.

To test if this was a case, go to the project, then click “Create” (YOU HAVE TO GO TO THE PROJECT FIRST). Once your create screen is up, click “Configure Fields” then “Where is my field?”

From here, type in your field name and click on it from the drop-down, and you’ll get a quick diagnostic on what’s preventing it from showing up.

As you can see, the bottom one is the offending item – which is your field context. However, this screen will even give you the link to where you need to go to adjust it. To fix this, click that link, then on the next page click “Edit Configuration”

From here, make sure your issue types and project context are appropriately set, then click Modify. You will need to reindex after this, but the field should now be accessible!

3. Updating your URL

So, for whatever reason you need to adjust your URL to JIRA. You do all the work on cut-over day. You have updated the base URL, DNS entries, and even setup Apache to redirect from your old URL to your new one. You get done, run one last test load of JIRA when you see….

Yep. That’s our third gotcha. Any time you change JIRA’s URL, you will need to change the proxy settings in conf/server.xml and restart JIRA. Specifically, the setting “proxyName” listed here:

Additionally, if you are changing the directory you access it from (lets stay from /jira to just /), you will need to update this path setting too.

Do that, restart JIRA and that error message should disappear!

4. App Compatibility

So, picture this. You’ve just completed a massive JIRA Upgrade, and everything appears to be running smoothly. However, come the next work day, you get reports that some features appear to be outright missing. Investigating, you look at your apps to find the following messages.

Image courtesy Atlassian.

Congratulations, you just fell for another gotcha. Your apps are not guaranteed to work version to version, so you need to check each time you plan an upgrade. If you are fortunate, the vendor has already released an updated version that works with your new version of JIRA, and you can just update it straight away.

However, sometimes (like in the case of the “Copy Space Plugin” here), there is no updated version available. You have few choices here.

  • First, you can try to request an update. Not every app is still supported though, so you may not get your update.
  • Second, you can try to find another app in the Marketplace that replaces the functionality. Again, this may also be a dead end.
  • Third, just decide that functionality was a nice to have, but not important, and go on with your life. Your users may disagree though – so be warned.

I suppose there is another option here if you know how to program, but I don’t expect all JIRA Admins to become Java Developers to, so this probably won’t be everyone.

5. Role based Permissions

So, you get a ticket in saying a user can’t work inside a project. No problem, you add them to the Developers role and call it done. Then the user reopens the ticket saying that they still can’t do everything they need to do.

Congratulations, you’ve just fallen for a classic gotcha. Depending on the permission scheme, the Project Roles may map out differently than in an unmodified JIRA. That’s why it’s always important to know what kind of permissions your users need and how they map to the project roles.

Seriously, I’ve used this exact scenario in interviews for JIRA Admins before. You’d be surprised how many fall for it.

6. Did you set a resolution?

So, you get another ticket from one of your Service Desk teams. No matter what they do, they can’t get a ticket to clear out of their queue. You look, and all the tickets appear closed, but there they are, still in the queue.

You’ll find this in teams that have customized their workflow. They forgot to do one of two things: Either auto-set a resolution or put a screen up to allow the user to select a resolution. JIRA Does not consider any issue truly done until that field is set. And that’s for both Software and Service Desk. But you will see this more from Service Desk teams, as it impacts them to a greater degree.

The main takeaway here is to always double check you are giving a user a way to set the resolution in every workflow you make for them.

7. Auto-assignment Roulette

So our last gotcha may not be your fault, but your users. Lets imagine this scenario:

You get an email from a project lead. They are actively using components in their project, with the components having their default assignee be their component lead.

However, they like to add multiple components per story, and no matter what they do they can’t seem to make the components auto-assign in a consistent way.

As you may have guessed, they have just fallen for the for the last gotcha. When using multiple components on a story, JIRA Will use the default assignment of the first component added to the list. So, if your teams are adding them in a different order every time, they will get a seemingly random default assignee every time. This one is easy enough to fix – just instruct your users of this fact and tell them to get a consistent result, order matters.

And those are some Gotchas to watch out for!

Is one of these surprise you? Do you have a gotcha that I didn’t cover? Leave it in a comment!

This topic was recommended by a colleague, but I’m always looking for reader requests for posts. If you have a topic you’d like me to cover, let me know!

Job Seeker Profile

So, as you know, I really started posting to this blog regularly when I myself was in the job market. So every now and again I like to feature those JIRA Admins who find themselves in a similar situation. And I have another one for you to look at.

His name is Akuthota Venkatesh, and he is based out of Hyderabad, Telangana, India. He has been a JIRA Admin in one form or another since June 2011. However, he has recently lost his job due to the world-wide slowdown brought on by the Corona Virus.

Some of the projects he’s worked on include integrating JIRA to Rally and Salesforce, migrating data to and from JIRA, as well as the normal spread of Application upgrades and dealing with stakeholders.

If you are looking for a JIRA Admin and think you might be able to help him, please download his CV and reach out to him!

And in other news

So, I was caught a bit off guard last week. As part of Atlassian posting about the blog, they asked if I had a twitter handle they could @mention. Well, I do, but it was mostly used for sweepstakes entries – not the impression I wanted to make. So since then, I have fixed that. You can find The JIRA Guy on Twitter here: https://twitter.com/theJIRAguy

I intend to post new articles and posts to twitter about our Atlassian powered lives that I find interesting, as well as new posts from the blog! So be sure to give it a follow. You can also subscribe directly to the blog to get new posts directly to your inbox! To do so, just use the form at the bottom of the post.

So, I’ve got some interesting posts planned over the next few weeks – even some that are not JIRA related! *gasp* So I hope you will check back in to see what we’ve got. But until then, my name is Rodney, asking “Have you updated your JIRA issues today?”

How to train your Workflows

You know what? We’ve been a little system heavy the last few months. Lets try something different…

So, we all know JIRA workflows. They guide your issues through their life-cycle, apparently only know three colors, and otherwise just sit there, right? What if I told you that you can train your workflows to do tricks? It’s true!

Today we will go over some of the ways I have trained my workflows over the years, and when you’d want to use each trick. The ultimate goal here is to get you to see your workflow as an equal part of the issue life-cycle – that is to say not only as a faithful guide, but an active participant!

Some of these tricks will require a plugin to enable – but where so I will clearly mark them as such and give you a link to the plugin.

With that being said, let’s get into it.

Conditions, Validators, and Post Functions, Oh My!

So to get started, we’ll need to review the three parts of a transition: The Condition, Validator, and Post Function. Each of these are evaluated at a different part of the Transition execution, and therefore are able to do different things.

Conditions

These are evaluated any time JIRA needs to see if you are even able to see that the transitions exists. On the surface, seems straight forward enough. If a user doesn’t meet the conditions, they don’t see the transition, so what tricks could we do with that?

Trick: Secret Cleanup Transition

So, here’s the situation. As a part of your workflow, you require certain information be filled in to close issues normally. For example, you require a fix version be assigned to a new feature or bug. This is because your users had a bad habit of just closing critical bugs that really needed to be fixed.

Which is great, but as time goes along, the project lead comes to you, saying they have too many issues that being honest, they won’t ever get to. However, you realize that because of the requirements, you can’t just close those issues. You obviously don’t want to get rid of the requirements, but you want to enable the Project lead to do their cleanup. How do you do this?

We can do this simply with one condition! First we’ll add an “All” transition to the closed state we’ll call “Cleanup” Then we’ll put a condition on it that says only Project Administrators can see this cleanup transition. This way we don’t open up the workflow to the abuse we’ve previously tried to stop, but we give the Project lead the power to cleanup when they need to.

Validators

Validators are similar to conditions in the fact that they evaluate whether a transition could occur. However, the key different is WHEN they do their processing. Conditions are evaluated before a transition ever occurs. On the other hand, a validator is evaluated during the processing of the transition.

One thing Validators are great for is that when they fail, they provide an error message. When a condition fails, the relevant transition just doesn’t show up. From experience, this usually leads to a lot of panicked questions from new people saying “I can’t close an issue!” This problem is avoided entirely if you use a validator instead. “Oh, I can’t close it because I need a Fix Version – cool.”

Trick: Written Approval

Note: Requires JIRA Misc Workflow Extensions

So, you have an approval chain workflow, but you want to be sure whoever approved it really MEANT it. Lets say this involves a P.O. process, so you want to know whoever approves it really meant you to spend that money.

This is easy enough with JMWE’s “Comment Required” Validator. To make sure the phrase is added as, we’ll add a conditional to evaluate the comment field.

issue.getAsString("comment") != "I Approve"

This is a bit counter-intuitive, but the condition is what makes the validator active in JWME. Here, the validator only ever validates if the comment is anything other than “I Approve” – which includes an empty string! Having the comment be “I Approve” disables the validator and lets the transition occur!

Post Functions

Post functions have no evaluation purpose, but are executed “After” all conditions are evaluated and things are ready to move forward. This gives you a chance to update fields, fire off internal events or web-hooks, or a myriad of other tasks. Most of the time when I’m looking to automate some function that is based on a workflow, Post functions are where I’ll look to first.

Trick: Auto-assign on transition

So this is great for any situations where a specific person needs to do something on a specific status….such as an approval chain. This lets you set it up to reassign the issue on demand without having the user remember to take that action. Very Handy!

To accomplish this, we’ll use the “Update Issue Field” Post function, select “Assignee” from the drop-down, then select the last radio button to specify which user you’d like to transfer it to.

There are additioonal post functions from various Apps that will do the same thing, but you can do this with just vanilla JIRA Functionality.

Workflow Properties: The forbidden technique

Okay, so maybe I’m being a little dramatic…

Transition and Status properties are a powerful technique for customizing how your workflow behaves. However, they are somewhat hidden, dubiously supported, and tricky to get right. Basically, if you do choose to go this route, you will be pretty much on your own, with your only company being whatever articles you can google. By the way, Hi googlers! Welcome to the blog!

In general, I don’t really like to use Workflow properties, but there are some cases where they can’t be helped. One use case I’ve used them for is to limit who can reassign an issue in a given status…which being honest I learned from another blog.

To access the properties screen, select your transition or status of your choice, then click “Properties”

This will open up another screen where you can see a list of that item’s properties. By default there should be none.

Trick: Re-order the Transition buttons

So lets say you have a project lead that is a little…particular. They want the most relevant transition to be the first button, with anything else being second. But you can’t re-order the Transition buttons, right?

Well, I wouldn’t be writing this section if that was the case. We can use a property on each transition called opsbar-sequence. This is a setting that will allow us to specify which transition gets priority on the issue view screen. To do this, we’ll need to add the key “opsbar-sequence” to each transition, along with a unique value. It is recommend you increment the value by 10’s on each transitiono, so if you add more transitions later, you have a place to put them between existing transitions

Remember, in this arrangement, the lowest opsbar-sequence value will go first, with each increasing value following afterwards.

You are now a workflow trainer!

My goal here is to get you to think about different automations you can enable for your users. It may seem trivial to you, but if you can save them 10 seconds on each transaction, that can really add up over time. And you don’t have to stop with this list! Look over what post functions, validators, conditions, and yes even properties you have available, and keep an open mind when you get these unusual requests.

However, a word of caution. If you go crazy with these, you may find you have too many workflows and actions within workflows to manage. It’s best to think of it like candy. Every once in a while is fine, and can make you feel happy for a bit. But too much too often can make you regret it before too long!

As always, don’t forget to subscribe to be notified by email of new posts! You’ll find a signup form at the bottom of the post. Also don’t forget to check out our Atlassian Discord Chat! It’s still ramping up, but I’m always happy to see people getting questions answered there! https://discord.gg/mXuRsVu

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

A JIRA Guy’s New Years Resolutions

HAPPY NEW YEARS! I hope you had a good 2019 and look forward to a great 2020!

As you know, 2019 was at times….rocky, but all in all it wasn’t terrible. This blog has been one of the bright spots, actually! Hearing from readers out there about how much they are getting from the blog really just makes my day every time!

Where I live, it is a tradition that we resolve to improve at least one aspect about ourselves over the new year. So, that got me thinking, as JIRA Admins, what can we resolve to improve about how we work and how we run our instances. So without further adieu, here we go!

I resolve to not make any config changes without notifying all users first.

This one is easier said than done. But this one will save you so much headache in avoiding unexpected impacts from a change.

The challenge here is there are a lot of changes that you think will have no impact on user experience, and it’s tempting to just rush in and change it. Especially when explaining what you are changing and why feels like writing a light novel. I know, I’ve been guilty here too!

But giving yourself a chance to pause to explain what you are doing and why you are doing it will give both you and your users some perspective. If you are having trouble stating why you are making a change in a way that normal users can understand, do you really understand the change you are about to make? And if that’s the case, why are you making a change you don’t fully understand?

Now another thing here is this requires some lead time. If you send out a rushed email than immediately make a change, you haven’t really notified anyone. It’s the giving it time for users to digest the information and send in the feedback that will show the true power of this resolution.

I resolve to clean up Custom Fields from JIRA.

I see this one all too often. JIRA went through a “wild west” period where either a) all user requests for new fields were automatically stamped “Approved”, or b) everyone had admin rights and just added fields without a care in the world. It’s nothing to be ashamed off, but it is something you should resolve to fix, as an over-abundance of custom fields can cause system performance problems.

Now I’m not going to lie, this is a political quagmire if ever there were one. Users LOVE their custom fields, especially Project Managers. So if it were me, I’d start with the low hanging fruit. In this case, that would be duplicate fields. This one is easy for users to see why it can be a problem. Try doing a JQL search on a field that shares it’s name with another. Which field is which? Which has the data you need? Who knows!?

This does lead to the problem of what to do with the information contained in whichever copy you are getting rid of. Not going to lie, that is not an easy question to answer in Vanilla JIRA, and rightfully deserves a post all it’s own. However, the ever helpful folks at Atlassian Community has a few pointers to get you started.

If you manage to clean up those fields, then comes the next easiest category: Those that are “close” to each other in purpose or meaning. For example, lets say you have the following list of fields:

  • Dev Customer
  • Customer
  • Customer (Accounting)
  • UX Customer
  • Customer Number
  • Customer ID

You now have six fields, which all contain essentially the same kind of information. In an ideal case, any custom field you create should be “generic” – that is to say it should be general enough you can drop it in any project where it’s needed and it makes sense. In this case, I’d work with five of these groups and migrate them all to use the “Customer” field. It’s generic enough that the meaning can be used for all of these applications, and gets rid of five fields in one go.

I resolve to gain and/or regain control of my JIRA instance.

So this one isn’t as universally applicable, but for those of you dealing with it, it can be a hassle. You do the work, get things cleaned up in JIRA and the system working smoothly, just to have some guy – who lets be honest should NOT have JIRA Admin rights – come in, create 20 new projects with 40 new fields.

It’s a story that does happen. That is why you should strive to regain control over your instance, and be the gate-keeper for any such changes. Do you really need 20 projects, or because they are all short lived, could you do with one and utilize Versions/Releases to organize that work?

Now, I’m not going to say this will be easy. Anybody with JIRA Admin rights that aren’t you might have some clout – or at least the ability to complain very loudly to the right people. You will need to defend your decision to take away their rights by showing how the changes they are making are not following best practices, and are actually having a detrimental affect on the instance. But remember, YOU are the JIRA Admin. The health of the instance is ultimately your job, so state that clearly. And remind them that you are open to requests, but you will guide the discussion to something that is better for both the users and the platform.

I resolve to make myself as much of a priority as my systems.

I get it. Your teams and users depend on you to keep the system running and updated. You know what makes it easier to depend on you? Not burning out.

I’ll see it on reddit from time to time where a Sysadmin has passed away from a heart attack, or otherwise burned out and is switching careers. They are always the type who hardly ever took vacation, never took personal days, and felt like the weight of the company is on their shoulders. I’m telling you now – don’t be that guy. I mean I play around with these systems for fun in my spare time, and I still have to unplug every once and a while!

So if this sounds like you, just relax. And if you are at a company that would fire you for taking a few days off every now and again, you’re at the wrong company! Every company should be concerned about burn out, and if they aren’t that isn’t a healthy environment, and you should start looking now for a better year ahead.

Again, Happy New Years!

So, what are your JIRA Admin Resolutions? Are you doing one of the ones I listed here, or are you doing something different! Please let me know. Next week I’ll be reviewing a app (or plugin for us curmudgeons) that literally blew my mind when I saw what it could do. But until then, I hope you have a great start to 2020! I’m Rodney, asking, “Have you updated your JIRA Issues today tomorrow?” Happy New Years Everyone!