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

Using Jira For a Job Search…well…that’s a thing.

So, I’ve been quiet here for a bit. There’s a reason. At the end of July, I was laid off. I’m told it had nothing to do with my performance, that is was just a matter of us loosing a major client and the numbers not adding up.

Either way, that puts me squarely back in the job market, which has been my focus for the past month. However…

The Jira Angle

The thing about a job hunt is – you gotta keep on it. It’s on you to follow up with an HR representative and figure out whats going on. Don’t be pushy, obviously, but be engaged. To that end, it was quickly getting to the point last week where I couldn’t keep track of all of it in my head.

Job hunting is also a project – and I happen to know a good deal about a highly customizable Project tracking tool. So, I fired up my personal Jira instance, patched it up to 8.3.1, and created myself a new project: JobHunt (JOB)

This was a custom project from the ground up. It was as much a task to keep my skills sharp as it was to solve a practical problem. But I’ve also realized it’s a great way to show just how flexible Jira really is. So I’m going to break it down for you, so if you also would like to do something similar, you can.

Workflow

This project uses a simplified workflow. The reason I chose that style of workflow is simply the fact that it isn’t a terribly complicated affair. I don’t have to show parallel work on my end per application/recruiter, so there isn’t a need for subtasks, but at the same time I’m not trying to do automatic reassignments. Basically, a simplified workflow allowed me enough flexibility without becoming a burden.

Each status is a step in the process. As usual with such workflows, I like to use the past tense, with each issue in the project moving to that status when the appropriate condition is met, such as I’ve completed a phone screen with a given Recruiter or HR department, I’ve done at least one Interview with a given company, etc.

I understand this can probably be refined further, but the best way to see those refinements would be to use it, and in the past week of use those possible refinements have yet to reveal themselves to me.

Screen and Fields

The Screen and fields have a number of custom fields that I’ve added to the project to help with retaining pertinent information on each position. In detail they are:

  • CompanySingle Text Field – This is fairly self explanatory…it’s the company the position is with. In cases where it is a recruitment firm on behalf of another company, I’ll put this in the format of “Company (via Recruitment Company)”
  • Description – This is where I’m storing the Job Description. No need to create a new field when one is serviceable.
  • Job Location Label Field – This is a label field describing where the position is located. This saves me on retyping, as the location is usually only a handful of possibilities, but lets me add more on the fly without having to modify the field or reindex
  • Job URL URL Field – A URL field for a job listing so I can refer back to it later. It’s more of a “For your reference” field, and normally wouldn’t make the cut for my criteria for a custom field, but it’s saved me a lot of re-googling.
  • Job ID Single Text Field – a Field for storing a job ID number. This is helpful if I am contacted by mutliple recruitment agencies for a single position.
  • Recruiter/ContactSingle Text Field – Okay, so confession time, I often have a hard time remembering names. So – put a field for it. Then I can remember it was Sarah that I was speaking to about that position at that one company.
  • Contact Phone NumberSingle Text Field – places to remember the number for my Contact for a given position. It’s also meant to cut down on looking up information.
  • Contact Email Email Field – Does the same thing as the line above. If possible, I’d prefer an email rather than a phone call, so I usually give priority to this field
  • Last Contact Date Field – When I last heard anything on this position. This is useful for knowing a) when to reach out to a contact about a given position, or b) when to give up on a position should I not be contacted at all about it.
  • RateSingle Text Field – Simply put – what I’ve put down as my desired pay for a given position, or what the company is offering.

A note here, On all but the most intuitive of Custom fields, I’ve added a descriptor text. This is always a good idea, as even though it may be clear to you right now what a field is for, it may not be as clear to a user. Because this is my personal instance, I was a little more informal here than I would be on a corporate Production instance, but even then I still felt the need to be consistent with using them.

Dashboard

The Dashboard is a rather simple affair with four gadgets. Starting in the Upper Left, we have a Created vs Resolved gadget, then two Filter Result Gadgets, and then finally a two-dimentionsal Filter Stats Gadget. These are powered by three Queries. The first one is a simple query, which gives us everything not listed as done in the project.

project in (JobHunt) AND status not in (Done)

This is used on the two left most gadgets. The thinking here is the only time I care about one of these being done is when I accept a position, which would invalidate the whole reason for this project to exist. As such, beyond noting why I didn’t get a position, it doesn’t need to be on my radar, and thus I let it fall off my Dashboard.

I use the Created vs Resolved more to track how many positions I’m applying to each day. I’d like to apply to at least one per day, so this is more for personal goal tracking.

The Two dimensional Filter stats gadget is more for personal reference. I obviously want as many positions to move forward as possible, so this helps me see where they are as a group and encourages me to keep checking back on the various positions.

The second query is to list those that I need to reach out to.

project in (JobHunt) AND "Last Contact" <= startOfDay(-7) AND ("Contact Email" is not EMPTY OR "Contact Phone Number" is not EMPTY)

Basically, what this is doing is returning every position I haven’t heard back from in the past seven days, but only those that I’ve listed a contact phone number or email address for. It doesn’t help me to try to reach out to someone who I don’t have contact details for, so this is to help the list remain relevant.

The last query I use on this list is those I’ve applied to in the past seven days.

project = JobHunt AND createdDate >= -7d

This is again to help me visualize my goal of applying to at least one job per day. Now I don’t actively search on the weekends, but there are days I do get more than one position, so the average is usually better than one a day including weekends.

The Kanban Board

The final piece I want to look at is the Kanban Board. It’s fairly vanilla for the most part, with one column per status in the workflow above. The two areas I customized it, however, are two that don’t get alot of attention: the Card Layout and Card Color.

For the card layout, I wanted to be able to see the relevant information at a glance. As such, I’ve put the above three fields on it – Who is it with, where is it, and when was the last time I heard about it. This maxes out the card, but the Summary already answers “What it is”, and the “Why” isn’t something that will fit on a card anyways.

I also decided to use the card colors to help me identify how long it’s been since I heard back on a given position. This is more an aesthetic choice, but it does help me know what’s good and what’s in trouble.

Final Thoughts

So – I don’t know if this is going to help me in the long run – but as a Jira Admin, I do need to keep my skills sharp, so it at least does that. I’m going to try to post here more often, with my next post going to be on how to install Jira to a clean linux instance. Until then, I’m Rodney, asking “Have you updated your Jira issues today?”

Hitchhiker’s Guide to Other Team’s JIRA Projects

Introduction

So you’ve got your team project configured to a fare-the-well, and your team is running like a well oiled machine, and you are able to see it.  But then, the worst thing in the world happens.  A task comes up, and you are wholly dependent on an outside team to complete it before you can proceed.  How do you track this? How do you account for this?

This truly nightmarish scenario is what we’ll deal with today.  The fact is, this situation is actually fairly common.  No one team can do everything on their own, which means to some degree, we are all interdependent on one another.  Understanding how to coordinate work when this happens can mean the difference between successful completion and needless delays and cost.

What you can’t do

Lets start with what you can’t do.  The reason you can’t do these is that the associated things are limited to a project, therefore do not work for issues outside your project. In other words, JIRA itself will not let you do this.  You can ask, but I cannot change these things any more than you can as these are built into the code.

The first is put it in a release within your project.  Because a release is a project level config, you cannot put a foreign issue into your release.  You can get around this for querying if the other project admin is willing to create a release in their project with the same name, but this solution will not let you use the project release tools to track that foreign release.

The second thing you cannot do is transfer a sub-task to the foreign project.  As a rule, a sub-task and it’s parent MUST be in the same project.  This is hard-baked into JIRA, so there is no way around this…directly.  What you can do is use your subtask as a tracker in your project, and link it to the foreign issue.  It’s not as direct, as stated, but it is the recommended method.

What you should never do

That being said, there are a few things you should NEVER do.  In fact, they are considered two of the Seven Deadly JIRA Sins:

JIRA Sin II causes a problem because most teams here use some form of either scrum or kanban board to track their team’s work.  If you transfer an Epic to their project as a request for work to be done, these Boards treat those differently by putting them into the sidebar on the board’s backlog screen.  Here, they will be missed, which means your work won’t be done.

JIRA Sin IV is more a courtesy, but it is still sin worthy.  Most people will at the very least move an issue some sort of closed status when completed, and may even include comments to explain details or ask questions.  Skipping this will not only waste your time, but theirs as well.  Even If you don’t see any activity on your issue, try putting in a comment and waiting a few hours before you march to their desks demanding an update.  Maybe they had a higher priority item come in, or maybe they just haven’t gotten to it yet.  Maybe they thought it was a lower priority than it actually is.  However, stopping whatever they are doing right away so they can answer your questions that could have been handled by comments is not going to win you friends.

Well, what the heck can I do then!?

  1. Releases with the same name
    1. Pros – This is great for teams that use dashboards – as a query on only the release name will return results of all projects that share that release name.
    2. Cons – You lose all ability to track from a single project release view.
  2. Duplicate issue and Link
    1. Pros – This is actually the Atlassian recommended approach to handling this problem.  It gives you visibility without directly interfering with another team’s processes.
    2. Cons – You actually have to watch the issue and followup on it.  You may also have an issue updating the issue, depending on the other team’s permissions and setup. I Should state that this is generally not a problem, only in a few very specific circumstances, and we actively try to avoid this situation – but it does happen.
  3. Transfer story
    1. Pros – You get to craft the story how you see fit, and have it fully prepared before firing off to the other team.
    2. Cons – This can literally break another team’s workflow if you transfer it as the wrong issue type or wrong status.  For this reason, this is not really recommended.

Watching issues, your ace in the hole

So, you’ve created a story/task/what-have-you for the other team to work on.  Now what?  How do you know when it’s done? The answer is simple, yet this is the biggest problem people seem to have.  However, if you watch an issue, you can get JIRA to email you every time anyone transitions, comments, edits or even looks at an issue the wrong way.

This is your ace in the hole.  You’ll know when an issue has been worked on, and conversely when it has not.  This will then let you reach out and maybe post a comment asking “What’s up?”  As a rule of thumb, you should always watch issues you are sending to another team.

Heads up!

If there is one thing that will help get eyes on your issue and get an early ETA on it, it’s a simple “Heads Up”.  Reaching out to the project owner on chat saying “I just submitted XYZ-1234” with a link can help make sure it’s seen, and make sure the other team has all the info they need to proceed.  While a simple step, most people neglect this in favor of just dumping it into a black hole of a queue.  Don’t wait for a problem or an issue to be ignored, just reach out! It will save both your team and their team time in the long run.

What it really comes down to

The great myth of JIRA is that it will do the work for you and make your life easier. While it can make life easier, it merely provides an platform for you to organize your work, share it with others, and submit work requests to others.  It is still on you to do the communication, the followup, and the work, and this is no truer than when you have to work with another team.  JIRA will give you place to submit the work, but it is on you to do the legwork required in following up and making sure it’s done.  But use the tools it gives you to help! Write comments! Watch issues! Give the other team a heads up in chat when you submit an issue!  All this will make your next collaboration project a success.