What’s the deal with Jira Cloud?

October 7, 2020October 7, 2020 Rodney N.Leave a comment

So, a few weeks ago, I was contacted by Jira Gal Heather Rimmey. She had seen a comment I had written in reply to someone’s comment about Jira Cloud and Jira Server. It turns out she was having the same discussion with management and wondered if I had any thoughts on the differences between the two deployment models. And well, we all know I do! This week, let’s dig into the differences and discuss when one option may be preferable to the other.

As a note, I’ll be using “Jira Server” a lot during this post. Please understand it to mean Either Server or Data Center. While the two are very different deployment models and have unique feature sets, it’s an excellent grouping to keep this post from getting too confusing.

One is not better than the other.

Let’s get this over with first. I do not think a Server Deployment is better or worse than a Cloud deployment. However, I believe that they are very different creatures who both happen to bear the name “Jira.” That is to say, just because you have experience with Jira Cloud doesn’t mean you’ll transition smoothly to a team using Jira Server and visa versa.

That’s my most significant point, and one I cannot stress enough. Most groups I talk to fail to consider a certain “relearning” time that will cause overall productivity to go down after a migration. Your teams will need to learn how to do all the things they knew on the old platform. This can be offset a bit by training, but only to a point. It’s something to consider.

Control vs. Ease of Use

This concept, as I see it, is the main selling point of Jira Cloud. You don’t have to learn how to set up a server or run an upgrade. You request your site, and within moments you have a Jira instance! Congratulations.

And this is great! If you are a small team, you don’t need that overhead. However, just like everything else Jira, this is a trade-off. Atlassian is continually pushing out updates and upgrades to Jira Cloud. This model means you often get not only bug-fixes first, but the latest and greatest features that the On-Prem deployments may not receive for months or years.

But what happens when Atlassian pushes an update that breaks your processes? Like when they pulled the Cloud version of the Automation for Jira app before the built-in version was completely ready? Don’t get me wrong, I have staked my career on Atlassian’s products, and will be their biggest cheerleader as a result, but sometimes “oops” happens.

With a Server deployment, I can find these “oops” moments in a testing phase of an upgrade. I can then choose to hold off the upgrade until I find a workaround or Atlassian fixes the bug. But you don’t get that luxury in Cloud. The best you get is the ability to put off an upgrade by a few weeks – but only on their highest-tier plan.

Again, not saying this a bad thing. It’s a trade-off for getting all the new toys before the rest of us. But it’s definitely something to consider.

Site Names

This fact maybe just me, but I’ve always been fascinated by Product marketing and branding. As my wife will attest, if I find an interesting product packaging at a grocery store, I will derail the whole thing for a moment while I take a closer look. I’ve honestly purchased some products before so that I can take a closer look at its packaging. It’s kind of sad and funny at the same time.

What does this have to do with Jira Cloud? I’m getting there. Every Atlassian Cloud instance has the following URL Structure: <yoursite>.atlassian.net. What if you prefer jira.thejiraguy.com? Too bad – can’t do that with Cloud. At some companies, this isn’t a big deal. You can still have your company name somewhere in the URL, and that’s good enough.

But that’s not every company. Some companies feel having their URL there is essential for customer perception. I can’t say I wholly disagree with this idea, either. I intend to eventually do a review on a tool that allows you to put public sites (like Atlassian Cloud) on your domain, but even that is just a workaround.

However, on Server, that is the point. You set it up on your servers, so you will need to have the URL set up, too. So you can use whatever URL you have control over.

Scaling

This is a point I think Jira Cloud does a great job on. Look, no matter how robust your system is or how much care you take over your configuration, if your userbase continues to grow, you will eventually outgrow your single server instance? What then?

Well, you are looking at a migration to Jira Data Center. This process presents its own hurdles and challenges. Just like a Server to Cloud migration, not all Apps that are available for Server are also available for Data Center. You will likely have a larger instance at this point, which means you might be trying to move a large amount of data around. Not fun.

And what do you have to do to scale Jira Cloud? Either pay for more users, or on the odd occasion, pay for a higher tier. That sounds a heck of a lot easier to me.

Apps

While this will be my last topic today, it is not anywhere near the last difference between the two deployment models. I’ll be including some additional reading if you want to explore all the differences yourself.

However, I’ve already touched on this one in this article, and it’s probably one of the most annoying things about the deployment models.

Jira Server Apps are not compatible with Jira Cloud, and visa versa. What does this mean functionally? It means that if you are considering moving from one to the other, you have to sit down and look at every single App you are running and determine if they have an equivalent on the other model. And most of the time – there will be at least one or two Apps that don’t.

Then your job is to sit back down and determine if another App is available to give you the same functionality, or failing that, determining if you can live without that App. And honestly, having to find out if you can “live without” happens more often than not.

There is another effect to this incompatibility. I cannot count how many times I am searching for a plugin to solve a specific problem, and I finally find the perfect App. It’s well-reviewed and has a large install base. And the documentation is thorough and doesn’t look too involved. Then I look up and realize it’s only for a whatever deployment model I’m not on. It’s honestly enough to drive one mad sometimes!

And that’s it for this week!

Before I forget, big news from this past week! Atlassian announced that they are renaming Summit 2021 to Team 2021! I don’t think we know if this will be the same once we can meet in person again, but I’m still excited. They have also opened up submissions for Speakers for Team 2021. I’ve put in three presentations from some of my favorite posts over the past year, and hopefully, I can get selected! If you have any interesting ideas for presentations, breakout sessions, etc., why don’t you submit too! Nothing ventured, nothing gained!

However, if you’ve found this post helpful, why don’t you give it a Like? I post new articles every Wednesday, so you can sign up below to get it delivered directly to your email inbox! You can also find me on Facebook, Twitter, and LinkedIn, where I’ll post updates, news, and new posts – so be sure to follow!

Rules of Thumb

September 23, 2020September 23, 2020 Rodney N.Leave a comment

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:

Process Details
Shipping Address
Cost
Shipping cost
Reason Needed
Rack Assignment
Rack Position
Purpose
Shipping Date
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 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?”

Jira Blunders!

September 16, 2020September 16, 2020 Rodney N.1 Comment

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?”

The Jira Dream Team.

September 2, 2020September 2, 2020 Rodney N.1 Comment

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.

HelpDesk

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 Twitter, Facebook, 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?”

Yes, Jira can be fun!

August 26, 2020August 26, 2020 Rodney N.1 Comment

So, just saying, you guys loved last week’s article. It was a hit – and got the blog a new record for single-day page views.

That’s quiet the act to follow. However, I think it’s time we looked at the opposite end of the scale. Can Jira be used for fun? What are these fun use cases?

When we think of Jira, we often think work. Someone wants you to do something. Or there is something you are acknowledging needs to be done. However, I believe in the flexibility of the platform, so I’ve managed to find a couple of unusual use cases that prove Jira is not only for work.

Jeopardy, brought you by Jira

This one was brought to my attention by a colleague, but the original credit for the idea belongs to Dan Eads, who permitted me to share it. He came up with the idea for a Detroit AUG meeting. And let me just say, this is one of the best examples I’ve seen in a long time to prove Jira’s flexibility.

So, let me discuss how I set this up, based on the original Idea. My first step was to figure out my categories, and create a status for each one. I also took the time here to remove any extra statuses that wouldn’t be needed for this project. As a note, make sure this project is using a unique workflow that is not shared.

Note I use the “Allow all statuses to be transitioned to this one” option. This setting is more just to make my life easier, but it works well in this case.

Next, I needed to think about how to store the information. Each question will have three independent pieces of data tied to it: the dollar amount, the question, and the answer. Reusing as many fields as possible, I opted to have the summary hold the dollar amount, the Description contains the question, and a new field I called “Answer” to keep the answer. This new field was just a single-line text field, nothing to fancy.

You might ask, “Why I didn’t just put the answer into the description?” Well, I wanted to be able to click on the question in a Kanban board and have it display the question – to simulate how the problem is behind the dollar amount on Jeopardy. Having both the question and answer in the same field would then give away the answer. Hence the need to separate the two values.

My thinking here is there will be two windows open for this – one that is displayed on a projector or shared on zoom for the audience, and a second hidden one for yourself. The Audience view will have the Kanban Board, but you will pull up the issue itself to see the question and answer in your view.

Now that we have the workflow and the fields, we need to work on the Kanban board. I started by going to the Columns and removing all the default options – replacing them with my categories. I mapped each Column with its appropriate status, leaving the backlog and Done statuses unmapped.

I also went into the Issue Detail View and removed all fields from there – that way, when I click on an issue, the audience can see the Description clearly and read the question for themselves.

And that’s it for the project configuration. All I need to do now is create issues to represent each of the thirty questions on a typical Jeopardy board. I found a good resource for getting questions quickly was https://jeopardyquestions.com. But feel free to think up your own company or ACE specific questions!

As a final note, I found the best way to clear questions that have been answered using my setup was to go to the Kanban Board while the issue was selected, click the ellipses, and then click “More Actions…” After that, click Done, which will cause the question to fall off the board and onto an unmapped status.

All told, writing up this how-to took me twice as long as actually setting it up. The first board, complete with the configuration from scratch and inputting all the questions, only took me about 30 minutes. I’d imagine each round after that would only take half as long to set up – especially if you already have the questions picked out.

This game sounds like an exciting way to use Jira to have a bit of fun, so this is something I suggest you check out sometime!

So a Jira Admin wants to do some writing

So question: you have a Jira Admin who wants to write a novel. How would they keep track of all the characters, stories, plot devices, etc. that goes into that?

Honestly, I’d use Trello. I use that to manage the blog, so I don’t forget post idea’s I’ve had!

However, a colleague named Jesse Wisener had the idea to use Jira and Insight to manage all these threads. Now, I am no-where near the Insight master that Jesse is, but I think I see where he’s going with this, so I’m going to try to do it justice.

I’ll start by creating a new Empty Object Schema in Insight.

This gives me a rather large blank screen to work with. So now we need to start populating it! Click “Create Object Type” to start adding the broad categories. These will be things like Settings, Characters, Plot Devices, etc.

From here, we can branch out further, such as breaking up characters into “Protagonist,” “Antagonist,” “Extras,” etc. At this point, repeat for all the other categories as you write ideas down and need expansion. Is your protagonist exploring a new dungeon? Write the details down in a new entry under Settings. Do they find the one sword that will defeat the dark lord? That’s a plot device. This method is an easy way to keep these various elements organized.

Honestly, I’ve done something similar for a collaborative writing project I’ve been known to help with. I used Confluence spaces for each broad category, but it still is the same concept. This shared world we write in has been around for many years – long enough that some of the histories have drifted into “Lore,” but we still use Confluence to keep all these things in our collective memory, and it’s worked well for us so far.

And that’s it for this week!

I know this is a relatively short post. However, I’ve had a busy week, and I don’t see it slowing down just yet. However, many exciting things are lining up!

This Friday will be the first anniversary of my first post to get a lot of attention. Considering where I was last year – the change is fantastic. I’ve stated it before, but I was hoping a potential employer would read the blog back then. I consider this post the blog’s real start – as that is when I started posting regularly. To see how many of you read it every week now is more than I could have ever dreamed, so thank you.

Second, Atlassian invited me this past week to look at some of the new ideas they have brewing for Jira Cloud. I cannot share any details yet (it’s very VERY hush-hush), but I am very excited about what they are doing. Honestly, I cannot wait to be able to share the news with you!

And finally, there is a new book on Jira Governance out. It’s called “7 (non-users) stories on (not only) Jira governance“, and I’ve gotten a copy to review. I’m only halfway through it, but I like what I’ve read so far. I’ve always dealt with governance because someone had to, but it’s never been a strong-suite of mine. So I’m looking forward to writing up the review for next week!

If you’ve liked what you’ve read here, don’t forget to leave it a like, comment, and share on your social media of choice. You can find me on Twitter, Facebook, or LinkedIn with the latest from the blog. You can also use the form below to get new blog posts delivered directly to your inbox! But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

Jira Sucks, but it doesn’t have to

August 19, 2020August 19, 2020 Rodney N.2 Comments

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?”

The System is Down!

August 5, 2020August 4, 2020 Rodney N.Leave a comment

Well, we made it to August! I hope you enjoyed App Month. To be completely honest, I only realized July had five Wednesdays after I had already committed to the idea. Oops!

But I got to meet some really great Atlassian Partners, learn some cool things about some Apps, and in general had a lot of fun. And you guys seemed to like it too!

Another record breaking month, with an additional 800 page views on top of June. To put it mildly, you guys killed it! Let’s see what August holds!

Today we will be looking at what you should do when Jira is down. As usual with us, this only applies to Jira Server and Data Center. Look, no matter what we do, Jira will come down unexpectedly at some point. That’s just one of the joys of running any service. If you are lucky and are monitoring all the right metrics, it may only come down when you plan for it to. However, everyone’s luck runs out at some point. So lets take a look at what we can do now to be prepared.

Have a Plan

There was a time, early in my career, where I didn’t plan for downtime. When downtime happened, I was all panic, no purpose. I’d extend downtimes longer than they needed to be so that I can find a permanent solution. This ladies and gentlemen is an inadequate approach when people depend on your system.

When people depend on your system to do their work, every hour it’s down is an hour the company is paying them to do nothing. I once had to break it down like this for a software engineer who wanted me to keep Jira down until lunch.

Let us say you have 400 Developers, with an average salary of $150,000/yr. That breaks down to roughly $72 per hour per Developer. That means a Jira outage cost you $28,846 in lost productivity every hour, and that is just Developers! It does not include Project Managers, IT, Management, UI/UX, QA, and everyone else that depends on Jira. You can see how it can quickly add up.

However, it is possible to be too hasty here too. You could be destroying information you need for a permanent fix by performing a quick fix. In that situation, you’ll likely have a ticking time-bomb, ready to bring down your system again.

That is why it is essential that you have a plan. Ideally, a document that describes whom to contact, what information to gather, and when to escalate. The industry term for this document is a Runbook, and it is recommended you have one for every system you manage.

In the past, I’ve linked to a generic Runbook template – and to be honest, it wasn’t the greatest for Atlassian Products. Atlassian themselves have a template that I like better than the one I’ve previously linked. However, I’ve taken the time to customize it further into a generic Jira Runbook template. This request came out of my last Webinar, and I thought it was a great idea! It will still need a lot of information specific to your instance filled in, but at least it’s a start!

MJD-JiraRunbookTemplate-040820-0918-13

Communicate Immediately

So, you’ve got a plan, and you’re following it. Good. But remember, many people need Jira and can’t get to it. Keeping them in the dark only means dealing with that many more interruptions while you try to fix things. They need to know what’s going on, even if the single update is “I know about it, I’m working on it, and I’ll give up updates as I know more.”

There are several ways you can do this. I had a list of email groups in Outlook that I could copy/paste into a new email. This method meant I didn’t have to remember who all I needed to contact – as again, I usually had other things on my mind. I just wrote up my message, pasted in the BCC, and hit send.

<pet-peeve> By the way, that’s another thing. For large chains, use the BCC rather than CC or TO lines. That way, if anyone needs to reply to you, they can without interrupting everyone else. </pet-peeve>

Another option you can look at is Statuspage. I’ve always liked the product, even though I never had the benefit of working with a group that used it. Training your users to check here for issues will help them find information on outages first without bothering you. Doing this sounds like a win-win to me.

Collect Information

So, you’re following your plan, and you’ve notified your users. Next?

Next, you need to take time now to gather information before attempting a restart. Typically, I like to have the following two things in case I need to go to support.

1: Thread Dump

A thread dump is a detailed list of everything Jira is doing currently and how long each task is taking. Having these details can be invaluable in determining why Jira is behaving weirdly or being slow. Atlassian provides a script now to automate capturing these thread dumps. Check out the docs on Thread Dumps here:

Troubleshoot Jira Server performance with thread dumps

As a note on Thread Dumps, if you install a plugin called Thready, it will help you analyze the thread dumps by attaching the thread’s name to each entry. It’s a free plugin and doesn’t impact performance, so I usually test and install it on my instances to be ready.

2: Support Packet

The support packet is another thing I try to capture if I can. Getting this will depend on your Jira instance being alive and responsive, so you may not be able to get it. If you can’t, don’t worry. Capture your log files from <Jira Home>/log/*.log, and you should be good to go. But the idea is before you try to change anything to get Jira back up, take a moment to get things that will help you solve this problem long-term.

Try to change one thing at a time.

So, you’ve collected the evidence, and you’ve told people you’re on it. What now? You can run in like a firefighter, make eleven changes, and pray one of them fixes Jira, right?

WRONG! Look, you’ll want to tell your management, your users, and your future self what went wrong and how you fixed it. You can’t do that if you aren’t sure what fixed the problem. That is why you need to take a breath, calm yourself, and focus on one change at a time. Change something; see if it works now. Change again, repeat. Do so until something works. You will still need to pay attention to the logs and hunt for clues on google. But take your time, and be methodical, and be sure what your problem was when all is said and done. You will be thankful for it; trust me.

Did I say Communicate?

Congratulations, you’ve gotten through the worst part of it. Jira is now back up and running, and everyone’s happy, right?

Well, no. First thing, you need to let your users know Jira is back up and ready for use. They are waiting to do their jobs, after all. Some of them will find it’s working on your own. But it is common courtesy to let everyone know.

Document, document, document!

For some, this will be the worse part. It’s excellent Jira’s up and running, but some people (like your management) may have questions about what happened. And these are not people you want to keep in the dark.

I typically write a document that I call an After Action Report. I’ve also heard them called Root Cause Analysis, but and After Action Report makes me feel more like a hero after a big fight. Yes, it’s an ego thing.

Typically, I’m looking to answer three questions:

What went wrong. Include a timeline of events, and the major players and systems involved.
What you did to fix it short term. Be detailed, and write down procedures and commands. You never know when having these handy will save you time in the future.
How you intend to keep this from happening again. Action items here could either be permanent fixes to be done, a followup with Atlassian support, monitoring on a specific metric or component, or a change to Standard Operating Procedures. The idea is to show you intend not to let a problem become a pattern.

Keep these in the same place (Confluence!). Again, if you’ve done your job right, you may never have to reuse one. But it’s handy to have it there and helpful if you ever need to refer to a fix you’ve found before.

Congratulations, you’ve survived!

Having downtime can be one of the most stressful events of your career. I should recount the time I was on duty for twenty-four hours straight with a severely troubled Jira instance. To be fair, I only spotted the problem after taking three hours to get some rest – so had I gotten some rest sooner, I may have resolved it that much faster. Seriously, don’t be me!

What are some of your downtime stories? I’d like to hear some of them in the comments! In speaking of comments, next week I’ll be compiling all the questions I’ve gotten in the comments and on DM’s into a post! If you have any questions you’d like me to answer, go ahead and get them in!

If you’ve enjoyed this post, be sure to follow the blog to get new posts directly in your inbox! You can use the form below to sign up! You can also follow us on Facebook, Twitter, and LinkedIn to get the latest updates! Be sure to like and comment on the posts, so the social media networks know the Jira Guy is worth sharing! But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

More JQL Tricks

June 17, 2020July 10, 2020 Rodney N.5 Comments

Well, we’ve made it another week. And let me tell you what a week it was. You guys killed it on the previous post – it’s currently the second most viewed post on the blog – and on it’s way to becoming number one! Thank you all so much!

Today’s topic also mirrors another popular post. I am looking at several more JQL tricks you can use to optimize your queries. Some of these are suggestions that I got in response to my previous post, some are new tricks I’ve learned, and some are stuff I cannot believe I missed. Lets get rolling on this.

Starting with the Basic search

So this was one of the ones I got as feedback from my previous article on JQL, thanks to Ed Gaile. And the trick is so simple I am ashamed I forgot to include it. This trick is when you start building a new query – start in basic mode.

Starting with the basic search will allow you to define parameters easily. Then, once you do so you can switch to Advanced, you can see and edit the JQL String.

One of the most significant benefits of using the basic mode first comes with adding a time-based parameter. When you do so, this handy pop up will appear to let you define your exact timeframe with no hassles!

membersOf()

We covered previously how powerful the currentuser() function is. It will let us easily customize a single query to whoever views it. Let’s consider this situation.

Your QA team consists of Bob, Lisa, Jerry, Beth, and Chris. You want a query that will return everything assigned to QA. And go!

Your first instinct is to write a query similar to this:

assignee in (Bob, Lisa, Jerry, Beth, Chris)

While functionally correct, this can cause problems. Let us say Jerry is tapped to become a Program Manager. You now have to go back and update your query. Tom joins the team now to replace the vacancy left by Jerry. Another update. What if there is another way?

If your team is within a JIRA group, you can reference that group directly in a query. Let’s assume the same situation, but we know the JIRA Admins use group jira-qa to manage permissions specific to QA. We can then replace the above query with the following:

assignee in membersOf("jira-qa")

The benefit here is that the Admins will update the group to change out Jerry’s job function and on-board Tom, so your query requires no changes to stay up to date.

If your instance is using Active Directory syncing, you might also be able to leverage AD Groups directly in JIRA. The benefit here is as your AD Groups are updated, the change is automatically reflected in JIRA, and therefore your query!

lastLogin()

So this one is very situational. Let us assume that as part of a triage operation, you want to make a query that shows everything that users created since the last time you logged into JIRA.

You can write a query that looks for everything created in the past day, but that will only get half the data from the weekend. Plus, for most weekdays, that will include issues you’ve already triaged. Not ideal.

That is where the function lastlogin() comes in. This function will return a timestamp from your last login so that you can find new issues. In practice, it looks something like this:

issuetype=Bug and createdDate >= lastLogin()

This function also works with updatedDate and resolutionDate, so you can find issues that were updated or resolved since your last log in. For Triaging and reporting, definitely a good thing to have in your toolbox.

Filter using another filter

All right, here’s one I found as research for this post. And honestly, I didn’t even know it existed. You can reference another filter in your query, and add onto it!

filter = "Filter Name" AND ...

Yes, this is a real thing! You can use this trick to narrow down the results of a query further, or two build several variations on a query while abstracting out the common parts. It amazes me to this day that I can have studied this platform extensively for years, yet I can still find something I genuinely did not know!

Subscribing to a Saved Filter

So, let us go back to the Triage example from the lastLogin() section. You’re happy with the results, but you hate that you have to log in to JIRA each morning to get started. Maybe you’d like to review the results on the train while on your way to get a head start? You can use JIRA’s Mobile App, but that won’t remind you to do it.

There is a way to get JIRA to email you the result of your query on a set schedule. This trick is called a subscription, where JIRA will run the saved filter based on your permissions, and send you the results via email.

To set up a subscription, first navigate to your saved Filter. Then click “Details -> New Subscription”

Once there, you can set up which groups (to which you are a member) will receive the query. You can also select “Personal Subscription” (which is the default) to send it to yourself. Afterward, select how often you would like to receive the filter results and click “Subscribe.” Congratulations, you will now start regularly receiving the Query results.

Searching through the Past

So, it is now time for “Admin Storytime” with Rodney. Once upon a time, a Project Manager came up to the brave JIRA Admin nervous. One of the villagers wasn’t too smart and had closed many issues that shouldn’t have been. The Project Manager was scared that this would mess up their project, so he needed our hero’s help in finding all the closed issues and reversing the dreadful curse.

So what did the hero do? He did a historical searched using the Changed functionality.

For those not familiar, you can use “changed” to take a look at what a field value was, who changed it, what they changed it to, and when they changed it. In this case, the query looked like this:

status changed to Closed by Villager after startOfDay()

I would note that not all fields support this kind of searching – in fact, the vast majority doesn’t. Status, however, is one I can usually search the history on, so it’s handy to keep in mind.

sorting

Sorting your returns

So, most of the time, the order you get issues back in is not essential. But sometimes, it does help you understand the data if you can sort it by one metric or another. This situation is where the “Order By” function comes in.

reporter = currentUser() order by created ASC, updated DESC

This function allows you to specify what order you’d like to receive the results. For example, you can sort it by date created in Descending (DESC) to get a list of results sorted from the newest to the oldest. Put the field you’d like to sort by, and then the direction you want to sort on, and you are off to the races.

You can also sort by more than one field. For example, you can first sort by the assignee to get an alphabetized list of issues by assignee, then sort by Updated to get the newest issues touched by each user on top of each user’s results.

I should note that not all gadgets respect the Order By function, so your mileage may vary on Dashboards, but it’s still something handy to keep in mind.

So, what are your favorite JQL Tricks?

As I have noted, some of these I got from your comments on the previous JQL post. So what other JQL tricks do you have? Post your favorite tricks, and I may share them on a future post!

If you are in the Atlanta, GA area next week, I’ll be speaking during the first half of the (Remote) Atlassian Community Event on how to set up Nagios to monitor Atlassian Applications. I hope you will join us!

Don’t forget to comment, like, and share this post on social media of your choice to help spread the word! As I said, you guys have been killing it this month on the numbers, and I want to see if we can get an all-time high! Also, be sure to follow me on twitter at @theJIRAguy.

And as one last note, check out the newest Atlassian Blog on the block, run by my good friend Kris. She will also be posting weekly! Her blog will be more focused on the Super-User aspect, so it should be an different yet much needed point of view. http://www.notesfromkris.com/

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

Automation for JIRA

May 20, 2020July 10, 2020 Rodney N.Leave a comment

So, I can already hear you, readers. You’re saying, “Aren’t we supposed to have a part 2 to the Dragonslayer post where you modernize the instructions?” And you are correct. However, that turns out to be a more significant task than I first imagined.

However, I want you to have something to read this week. That was when I had a request from a client this week. Upon reviewing the solution to the request, I felt it would be perfect for posting about this week.

Automation for JIRA

One question users always ask me is how they can automate actions in JIRA. For example, when they move a story into the sprint, how can they automatically have the subtasks moved too. And for the longest time, I didn’t have a useful answer.

Sure, you can make it work in Scriptrunner, but the amount of work it would take would make it not worth it. Then I discovered Automation for JIRA. This one allows me to tailor automations to specific projects, and so so using no programming.

So for this post, I thought I’d go into the request I was given and how I approached solving it using Automation for JIRA. Let us begin.

The Request

So, my first recommendation is to understand the request entirely. Figure out not only what the users are asking you to do but also why they are asking it in the first place.

In this case, the client asked me if there was a way to automatically create sub-tasks on an issue based on what components are on the parent issue. That’s great, but that doesn’t solve the “why.” However, I was fortunate that the client already explained their thinking here.

It turns out that the client has the components in their project broken down by functional teams, and for each task, they want to add Components to the issue based on who has an active role in it. They then want to create a sub-task for each component so that the individual teams involved can track their work.

The reason for the requests tells me a good bit about the request that the initial ask did not. For example, Components may not only be added at issue creation but at any time during the Issue’s lifecycle. This fact comes into play soon. It also tells me that I need to be able to support any combination of components. This requirement can make things tricky, but I don’t think impossible.

Getting started

The Trigger

The first thing I think about when I start building an automation is, well, the starting point. What kicks it off. Let me explain. For every automation rule you have, you need some event to kick it off. Some marble that is falling to set off your Rube-Goldberg machine.

In Automation for JIRA, this is called the Trigger. There are a number of these available within the tool.

That is quite the list, no? While it may be something to go through, I think it’s a natural choice here. Remember when I mentioned that we discerned from the request that we would need this to happen at any point during the Issue’s active life cycle? That means we can rule out anything that doesn’t have to do with the Issue. We can also rule out anything that takes place during specific events of the lifecycle, such as a transition or creation.

Furthermore, we have a trigger that can focus specifically on when a field is changed.

So when we select this option, we are presented with several settings. Because we are focusing on the Components, we choose that for the field setting, and leave the “For” setting to it’d default “All issue operations.” Once done, we click “Save.”

Conditions

So, now we need to think about when we don’t want this rule to run. We can specify when an automation rule runs by using “Conditions.” Here is a view of what our rule looks like after saving the Trigger.

We know we only want this rule to run when the parent issue is active. So lets put a condition on here to check that the Resolution field is empty.

Having this immediately after the Trigger keeps it from executing when this condition isn’t true (in our example, when the Issue is resolved). There are many conditions available, and we can use a few of them here in a moment.

The “Component Block” – More Conditions and Actions

Now comes the tricky part. We need to be able to split off actions based on the components. We also need to check – per Component – that it’s appropriate sub-task doesn’t already exist. This requirement stumped me for a second until I settled on the “If/Else” block. Using this condition creates a situation where you can have actions run if the condition is true, but if it’s false, it won’t stop the entire chain from running.

Here we have the If block with two conditions. The first checks for a specific Component – in this case, “Ducks.” The second checks all sub-tasks to make sure we don’t already have the one we want. If any have the summary “Test Ducks,” this Trigger fails, and any actions we have on this branch don’t run.

What do I mean by branch? I mean this If block, once saved, creates a branch in our rule flow.

Here is where we will add our actions. In this case, we will want to create an issue within the current project with issue type “Sub-Task”. This will allow us to specify the responsible user, description, and most importantly summary. For this to work properly, you need to make sure you summary you are creating matches the check you have in the If Statement.

Click Save, and that’s the block done for this Component. Rinse and Repeat for each Component you desire to automate, and you should be good to go.

Branches

So, we didn’t end up using them for this request, but I still wanted to touch on Branches. We used the If/Else Block for some rudimentary branches, but what happens when you want to run an Automation Rule against all the Issue’s Sub-Tasks?

In this situation, you want to use a Branch rule. This rule allows you to execute a set of actions on issues based on their relation to the Issue that triggered the rule.

Something handy to keep in mind, but as I’ve stated, not always something you need.

And that’s it!

I am sorry for not having the second Dragonslayer post – but I do hope to have that available for next week. But this request struck me as an interesting problem and a great example of how to develop and use an Automation Rule.

If you like the content you find here, don’t hesitate to sign up below to receive emails when I post new content. And you can also check me out on twitter at this link. But until next time, my name is Rodney, asking “Have you updated your JIRA Issue today?”

What is a Consultant?

May 6, 2020July 10, 2020 Rodney N.Leave a comment

Well, here we are, another month down. At let me say, you guys killed it last month!

We got well over 1,000 views last month! That almost doubles the previous month and is easily the biggest month the blog has had to date. Thank you all for commenting, liking, and sharing the blog with your friends and colleagues! You guys are what makes this all possible!

Today’s topic is a bit different. This item was suggested to me by a colleague. In a nutshell, he wanted me to look at the difference between being an Atlassian Admin and an Atlassian Consultant.

As you may now, I was a JIRA Admin before starting my current job. But seeing as I have only been a consultant for six months, I decided to call in some help. So welcome to the blog David Higdon, Olena McMurtrey, and Neil Taylor. They will be lending their thoughts onto the topic and answering some questions I posed to them!

How did you get started with Atlassian Components?

Neil: So, the first job I had out of college – they were running a helpdesk – and this was before JIRA Service Desk was around. But they were like, “Hey, We’re using this new product called JIRA.” And that was when JIRA was on version 4. So I got to adapt that to run a Service Desk for about ten thousand Dialysis Facilities. It was an interesting use case for the product, and I don’t know if they chose the right product for that, but it got me in the door with working on Atlassian.

Olena: Coyote Creek had both Microsoft and Atlassian teams; I started in the Microsoft division, and with time transferred to Atlassian team. I got passionate about Atlassian products, and enjoy helping clients to tune their systems with best practice approach.

David:

So, one of my good friends leaves the company I’m working for and joins a software company. And their Engineering Team at this software company was looking for somebody to help manage their middleware space from a Unix SysAdmin perspective. At the time, I had 27 years of experience as a Systems Administrator – of which I had spent six managing the middleware space, and they felt I would be a great addition to their team.

As this company was coming out of the startup phase, they were looking to get a little more structure in place and a bit more formality in their processes, and for someone to help them standardize and automate things of that nature. And being an Engineering Department, they are big on Atlassian Products. They had two instances of JIRA – one external for Professional Services and their Customers, and then an internal system for their Software Developers. They were using two instances of Fisheye/Crucible. The Professional Services instance looking at SVN and Engineering instance was looking at GIT.

So, my first day on the job, they sat me down, and they said, “Here you go, here are two instances of JIRA and Fisheye, and here are the hostnames.” I had to learn Jira ASAP and prepare to upgrade the system. So, I’ve never heard of Atlassian at that time, so this is how I got introduced to Atlassian – literally diving into the deep end.

Rodney: I was working as a consultant for First Responder Dispatch systems at the time – that being the systems the operator is typing into when you dial the emergency number.

However, that job required a lot of travel, which was not a good situation. Looking around my company, I noticed an open position for a Linux Administrator. Now this company prided itself on being a Microsoft shop – so of course, I was the one dumb enough to raise my hand and say, “Yes, I know Linux!” I applied and interviewed, and was honest about my experience, and got the position of managing some Linux based development systems.

So day one, I go in, and I’m getting the grand tour. We go over my server closet, the perforce server, our backup process, and finally, JIRA and Confluence. I’m given admin rights to the systems and told, “Congratulations. You have a day before you start getting tickets, and by the way, we want to upgrade the systems this quarter.” At that point, nothing left to do but start learning one ticket and google search at a time.

How did you become a consultant?

Neil: So, I put JIRA on my LinkedIn, and a consultant company contacted me and said, “Hey, we want you to come be an Atlassian consultant for us,” because they had a client that was using Atlassian products. I interviewed for the position, and they offered me a job, and I thought, “Well, hey, let’s give this a try and see some other Atlassian environments out there.”

I have to admit that Atlassian wasn’t on my radar when I was in college. I also didn’t see my career going from Atlassian Admin to Atlassian Consultant, but I’m happy with the way it worked out.

David: Over my years, I had quite a few opportunities presented to me before I joined Coyote Creek. I had offers for Backend Sales or Consulting but never took the opportunities. Before I joined Coyote Creek, however, I had two separate Engagements with them and enjoyed the experience and the expertise they provided. It was a combination of being a little older in my career. After twenty years of being on the front line supporting mission-critical applications, I was ready for a new role.

My introduction to I.T was as a Computer Operator working graveyard at Oracle. And about a year into the job, I met some Senior SysAdmins that worked in the Development Datacenter, and they had all the latest cool toys. As I built a relationship with these guys, and they told me more about what they did day today, there was one aspect of their job that stood out. There were never on call. I quickly discovered that being an Engineer for Developers and supporting their systems was the dream scenario. You get all the cool toys, do the same kind of work, but nobody cares if a system is down Saturday at 10 PM.

That job at the software company was my first opportunity for that kind of work – only supporting Engineers and Developers, and there is nothing mission-critical about code deploys because it was all about the next release. So that was my first dip into that situation I always wanted since starting I.T. Consulting is kind of a natural progression there, so when the opportunity came up, I made a move.

Rodney: Honestly, I avoided becoming an Atlassian Consultant for a long while. My previous experience with it left a bad taste in my mouth, and I worried about a repeat of that experience. However, when I was in the job market last year, it got the point where I had multiple offers. I was clear during the interview with Coyote Creek that I didn’t want to return to a scenario where I was traveling more than 25% in any given month ever again. They agreed, and all told they had the better offer, so I signed on with them. And it has been a much better experience than with my previous time as a consultant.

What do you feel is the biggest difference between being an Admin and a Consultant?

Neil: I think the most significant difference is that the consultant has the space to look at the bigger picture and to make the recommendations towards best practices. When you’re an admin in the trenches, you get so busy with the day-to-day “Hey, I need this workflow” and “I need this project” that you can lose sight of that. That’s where a consultant can come in and lead you away from some nasty rabbit holes.

David: You do not own the system or application. For where I am at in my career now, I am not looking to support environments 7x24x356, so this works out great. It can be challenging, though, if you want to make updates or correct areas you were not requested. That is still the old Admin in me. However, I still really enjoy Architecting solutions and problem-solving. I spent many years in the service industry, so it’s also the customer service aspect, and being able to provide solutions to people is what drives me today.

Rodney: That when we come in, we are there to solve problems. If these were easy problems to solve, the company wouldn’t have hired us. But, it’s not a “You vs. Us” kind of deal. We are ultimately there to help you, so don’t be afraid to ask questions and figure out what’s going on. After all, when everyone is on the same page, it will lead to a better outcome.

What do you wish more Admins knew about being a Consultant?

Neil: That our role is to make everyone’s lives easier – including yours. We’re not there to try and complicate anything, but instead to make everything easier. And a lot of times that includes making the Admin’s lives easier, because we don’t want the interface to be messy and there to be a bunch of overhead either.

At times I feel admins think, “Oh, they’re bringing in a consultant, they are going to try to to over-complicate this project.” But that’s not the case, we want to make everything easy too.

Olena: I think a lot of Admins don’t know how exciting it can be, how there is this non-stop race to learn new technology. It takes a very hungry approach where you want to learn new things and take on new problems all the time.

David: You do not come right out of school into a consulting role – spend time as an Admin or an Engineer to develop the technical skills to take on such a role. Additionally, develop the soft skills for communicating with your clients.

Rodney: That when we come in, we are there to solve problems. If these were easy problems to solve, the company wouldn’t have hired us. But, it’s never a “You vs. Us” kind of deal. We are ultimately there to help you, so don’t be afraid to ask questions and figure out what’s going on. After all, when everyone is on the same page, it will lead to a better outcome.

Final Thoughts

Neil: Being a consultant is unique because you are jumping from one thing to another. At times, it can be fast-paced and intense, but it keeps you from getting stuck in a rut. You are always learning something new, so you never feel you are getting stale.
Also, no one’s setup is the same, everyone is doing a slightly different thing, so it’s always an adventure.

Olena: To be a good consultant, you have to be a good Admin first, as you have to learn first-hand the pain-points of someone using the products daily. It’s like learning colors before you start the whole painting. It provides a background on how better to support clients to close the gap between the business and technical sides.

David: The best and worst aspect of JIRA is you can do anything 10,000 different ways, and as a consultant, you have to peel that back. It may or may not be the best way. But there have also been times I’ve discovered that the way I did it wasn’t the best, and the way that someone else implemented it was better than mine, so I can learn from that way.

Someone told me this a long time ago, “There is nothing more permanent than temporary!”. After all my years supporting everything from mission-critical environments to lab systems, I found this to be true. Countless times someone told me they would need access for X amount of time, or they rack some computer here for a week or need root for the day or need to run their app on my system until the budget is approved to buy new hardware.

Rodney: I feel that being a Consultant and being an Admin are two sides of the same coin. Each one emphasizes different skill sets, but you both build off of the same necessary base skills. But at the end of the day, it’s still up to all of us to learn and grow.

And that’s it for this week!

So, I’m trying something new with this interview format here – and honestly, I’m nervous about how it will play out. So if you enjoyed this post, please do take the time to like it and leave a comment!

Don’t forget you can also subscribe below to the blog to get it delivered each week directly to your inbox. You can also follow theJIRAguy on Twitter!

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

One is not better than the other.

Control vs. Ease of Use

Site Names

Scaling

Apps

Further Reading

And that’s it for this week!

1) If your workflow takes more than 30 seconds to explain, it’s too complicated. – Logan Hawkes (Coyote Creek Consulting)

2) If your workflow has ten or more steps, it’s too long. – Logan Hawkes (Coyote Creek) & Matt Doar (LinkedIn)

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

4) If you have more than 1000 issues in your backlog, it’s a history book, not a backlog. – Sean Blake (Easy Agile)

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

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)

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)

8) Start as simple as possible and only add complications to alleviate pain points. – Jesse Wisener (Coyote Creek)

9) Value your own time as much as you value others, and visa versa. – Rodney Nissen (Coyote Creek)

And that’s it for this week!

Always Double-check system commands

Label Your instances Carefully

Leaving your email on while Load Testing

And that’s it for this week!

What Everyone Needs

Team Lead/Product Manager

The Systems Guy

The Jira & Confluence Guys

Customizing for your Org

The Developer

The Build Guy

HelpDesk

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

Jeopardy, brought you by Jira

So a Jira Admin wants to do some writing

And that’s it for this week!

“Jira makes it challenging to create an issue.”

Required Fields

Too Many Fields

I can’t find my work in Jira.

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

Jira sends to many emails!

And that’s it for this week!

Have a Plan

Communicate Immediately

Collect Information

1: Thread Dump

2: Support Packet

Try to change one thing at a time.

Did I say Communicate?

Document, document, document!

Congratulations, you’ve survived!

Starting with the Basic search

membersOf()

lastLogin()

Filter using another filter

Subscribing to a Saved Filter

Searching through the Past

Sorting your returns

So, what are your favorite JQL Tricks?

Automation for JIRA

The Request

Getting started

The Trigger

Conditions

The “Component Block” – More Conditions and Actions

Branches

And that’s it!

How did you get started with Atlassian Components?

How did you become a consultant?

What do you feel is the biggest difference between being an Admin and a Consultant?

What do you wish more Admins knew about being a Consultant?

Final Thoughts

And that’s it for this week!