Yes, Jira can be fun!

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.

Audience View

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.

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

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

Answering your comments!

Just going to say this – I totally stole this idea for a post from Ravi Sagar

Honestly, if you are not following Ravi, you should be. I find it hard sometimes to come up with a topic each week, and this man comes up with one per day! He is knowledgable about the subject matter he covers and is always willing to help people further in his comments section. As I’m stealing this post idea from him, it’s only fair I give him a shout out.

Today we are going to look through some of the various comments, direct messages, and emails I’ve gotten over the past year. I answer each one personally still, but I thought it would make a fun post to share with you all. So, without any delay, let’s jump into this.

Counting Issues

“Thanks for these tips! Is there a way to use JQL to return a count of linked issues?” – Jen

So, without Apps, there’s not a great way to just get a number on a dashboard. You can get it with a two dimensional gadget and finding the “Total” line.

However, if we look at the question, they are asking for just a JQL to return a count. They don’t mention dashboards at all in their question. Considering that, we can definitely say that JQL will not return that directly, but you can still gather that information from the query screen. If we look at the places marked in red below, we can see the total number of issues returned in both the Detail view and the List view.

Sprints in Queries

“Can you help me with creating a query for all issues from a certain sprint onward? Right now I have to update the query for every new sprint.
project = AND Sprint in (488, 498, 482, 491, 502)
Any ideas? Thanks in advance.” – Tiffany

How you set up this query varies depending on which set of sprints you are looking for in relation to the current sprint. Tiffany isn’t completely clear on this point, so we’ll have to generate several answers to cover the range of possibilities.

Let us say they want the current sprint and all future sprints. Essentially, we are only excluding past sprints so that we can format our JQL as below.

sprint not in closedSprints()

We can, of course, add any additional conditions we want on there to refine the query further.

Let’s say that Tiffany instead wanted a query that only returned issues in future sprints. This request gives us an even easier JQL string.

sprint in futureSprints();

However, there is one more possibility here. It could be the fact that Tiffany is not looking for issues in the current or next sprint, but every sprint after that. To the best of my knowledge (and the docs), this isn’t currently possible in JQL. It would be a nice feature, as I can see something like this being useful. But as of right now, it’s not possible with Jira out of the box.

Formatting a response.

“Thank you for awesome content. My management is weird and they want a very detailed report on daily basis.
This is how they want the report
Row1 Story – – title, status
-> Row2 Subtask1 of row1 – – title, status
-> Row3 Subtask2 of row1
Row4 Story2
->Row5 subtaks of story2
And so on.. Problem is I tried using parent id but its not helping as they are not close.
Could you please help me?” – Priyesh

This one wasn’t easy to figure out. To my knowledge, there isn’t a great way to get your JQL return in a specific format like this. Sure, you can set your columns and sort, but showing this relationship from a JQL response is not currently possible.

So, as is usually the case when we are looking at something Jira can’t do, we turn to the Atlassian Marketplace. There I found Big Gantt. Long-time readers may remember that I don’t care for this app. It’s not because there is anything wrong with it – it works perfectly well. It’s more a combination of UI and how many fields it creates on the system that gives me pause. However, for this use case, it works perfectly well.

To get this to work, I had to set up a new “Program.” After loading it up, I had to go to Box Administration (the “gear”), then Tasks -> Task Structure. Here I enabled both Epic and Sub-tasks.

After this, I click “Scope definition” and made sure it included one of my test projects under the “Automatic Rules” dropdown.

When I go back to the Gantt section, I see my issues in the format Priyesh wanted them in. They can now capture it in a screenshot, or export it as needed.

Where can I learn more about Jira?

So, I have gotten several questions on this. It’s usually along the lines of “How do I learn more about Jira?”

To answer this, I still say one of the best ways to learn is hands-on. Roll up your sleeves, get in there, and get messy. This fact is also a reason I highly recommend you get a test instance or a personal instance. As I’ve often said, you can get a starter license for Jira Server for only $10. Considering the benefits to your future, it’s an easy buy.

When I started, I had to google everything. Doing that, I found great resources like Atlassian Documentation. Honestly, it’s nice to have a product so thoroughly documented.

But if you are interested, there are experts out there who are willing to put out material to help you. One such is Rachel Wright, author of the Jira Strategy Admin Workbook. And you’re in luck! Rachel recently announced that she has courses on LinkedIn on Jira Administration. Definitely a great place to start if you don’t know anything.

Of course, I’d like to consider this site another such resource to help you learn Jira. I’m always willing to take on additional reader-requested topics if they a) interest me and b) something I feel I can do justice. So feel free to send me any requests you may have!

Converting Apps to Data Center

“I just wanted some insights from you if it’s okay. We have few plugins that are written for server and now we are moving for data center.I’m sure there has to be refactoring and the atlassian documentation has best practices listed. However I found them generic and high level.” – Anupam

So…this one. I’m going to be real honest with you, readers. I’m not a very talented programmer. I’m passable, but I’m honestly embarrassed to show my code sometimes.

All that is to say, I don’t have a clue where to start on migrating Jira Apps to Data Center, either. However, this is where I remind you that the Atlassian partners are there to help you. There is a number who can help you with such a migration. So reach out to them and start talking!

Help with the ACP

This topic is another one that I get asked about often.

Let me be clear: I don’t have “dumps” of questions – or any questions outside the sample set available from the Atlassian University. Any such cheating would likely risk my ACP status, and that is not something I consider worth the risk.

With that out of the way, I stand by my original article on the topic. Atlassian provides a list of exam topics. Just to though and google each item! When you find a useful document for what you are trying to study, make sure you have someplace to put that link so you can refer to it again. Make sure you fully understand each point, and you’ll be fine.

The next tip I’ll give is brush up on your test-taking skills. I was lucky enough to read a book on the subject as I was preparing for my college entrance exam, and it has helped me ever since. And I still use those strategies to this day to help – especially on the ACP. Relax while taking the exam. Eliminate wrong answers, so if you have to guess on a question, you maximize your probability of getting the right answer. Go through and answer all the easy questions first, marking the more difficult ones, then return and take on the challenging problems. They ultimately will help you get closer to your goal.

The last thing I want to reiterate is the ACP is supposed to be a tough exam. The recommendation I got when I first started my ACP Journey is that you shouldn’t even consider the ACP Certification unless you have been working on Atlassian tools every day for at least two years. Not a part of your responsibilities – but your entire job. And having taken a number of them, I can say I agree whole-heartedly. However, they are not impossible. Atlassian has done a lot of work to get the difficulty exactly where they want it. And believe me, it’s always worth it when you see you passed the exam and rose to their challenge.

And that’s it for this week!

I hope you enjoyed this week’s post. It’s an experiment, and I hope it’s helped you learn something new. As always, let me know what you think with a comment on social media! Don’t forget to follow us on LinkedIn, Twitter, and Facebook to get the latest news and updates from the blog. You can also subscribe below to get updates directly to your mailbox! But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

The System is Down!

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! 

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:

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:

  1. What went wrong. Include a timeline of events, and the major players and systems involved.
  2. 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.
  3. 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?”