Category: Jira Workflows

Yes, Jira can be fun!

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.

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

How to train your Workflows

Rodney N.Leave a comment

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

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

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

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

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

Conditions, Validators, and Post Functions, Oh My!

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

Conditions

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

Trick: Secret Cleanup Transition

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

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

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

Validators

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

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

Trick: Written Approval

Note: Requires JIRA Misc Workflow Extensions

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

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

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

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

Post Functions

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

Trick: Auto-assign on transition

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

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

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

Workflow Properties: The forbidden technique

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

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

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

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

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

Trick: Re-order the Transition buttons

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

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

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

You are now a workflow trainer!

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

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

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

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

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

Rodney N.4 Comments

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:

  • Company – Single 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/Contact – Single 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 Number – Single 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.
  • Rate – Single 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?”

Workflows, huh, what are they good for?

Rodney N.1 Comment

Intro

Oh workflow, oh workflow, wherefore art thou workflow?  This is probably the least understood part of JIRA.  For example, here are just a few of the questions I get nearly weekly here:

No, Seriously…I get asked thse alot….

What is a workflow?
Why do I need it?
What can it do for me?
What can’t it do?		Which one do I pick?
What are my options?
Why can’t this be easy?

Needless to say, there needs to be some clarification on this subject matter – hence why it the first blog post I’m writing is about this.

What is a workflow

The workflow – to put it simply is the steps, or statuses that an issue travels through.  You can often see them displayed as such below.

These two are examples of a Simple and Complex workflows, respectively.  We’ll go into detail about what makes each what it is in a moment.  In this representation, each status is represented by a candy bar – with the issue’s current status being filled in. The circle in each is meant to signify the issue creation, and the arrows represent transitions between issues.  Please note that the first transition – from the circle to the destination, happens automatically when we are creating an issue.

Simpliflied Workflow
Complex Workflow

You can also note that each status has a color.  These are standard in JIRA – and we have no ability to change them.  Blue is meant to signify a start or backlog status, Yellow meant to signify an “In Progress” state, and Green meant to signify the end or termination state.

Basic parts

As shown above, there are two basic parts fo the workflow: Status and Transition.  Statuses are the boring part – they are what they are.  It’s meant to signify what “state” the issue is in.  For complex workflows, I like to make the status show what it’s waiting on, hence why they tend to be something like “Pending X” or “Waiting on X”.  The transition is where the action is, however. During transitions, you can have it automate certain actions – like reassigning the issue or updating fields.  We’ll go into further detail about this in another section.

Simple vs Complex

As stated, workflows can be classified into two general categories: Simple and complex.

A simple workflow is just that.  It only has three to four generic statuses, and each can be transitioned to from any other status (Marked with the “All” transitions above).  The purpose of these is to support teams who do a variety of tasks throughout the day.  The thought is your team will define the steps to completion using sub-tasking, and each sub-task will travel through these generic steps.  This also allows you to show parallel work – something a complex workflows cannot do.  In general, this is my advice for most teams.

A complex workflow is in many ways the opposite.  It has single status-to-status transitions, and more nuanced statuses.  This is great for highly regulated tasks, such as the requisition flow shown above.

In general, I advise the use of simplified workflows when possible.  They are much more adaptable should you decide to change how your team works.  With a complex workflow – any such changes will require you to work with a JIRA Admin to change the workflow appropriately.  However, for workflows that need tight controls, a complex workflow may be required.

Conditions, validators, and post functions

The Transition is said to be where the action happens within the workflow.  That is because there are three parts to the transition – the Conditions, the Validators, and post functions.  There is also the ability to display a screen to gather information relevant to the given transition.

Conditions tell the system when and to whom to display the transition button to.  If you cannot see the transition button, it is likely because some condition isn’t satisfied.  While a useful guardrail to prevent people from transitioning an issue who aren’t supposed to – it’s often confusing because you don’t get an error text – you just don’t have a button.

A Validator is similar to a condition in that it evaluate whether a transition can occur, but it happens during the transition.  It is useful to make sure people have filled out information appropriately – and is often paired with a pop-up screen (but doesn’t have to be).  Validators are often more useful as they do return error messages – making them ideal to make sure fields are filled out correctly.

The Post Functions run after the Transition occurs, and allows you to change fields within the function.  This is often how “Automatic Reassignments” are done within JIRA – by attaching the appropriate post function to the correct transition.  It should be noted that certain post functions have  to occur for JIRA to work properly – and therefore a JIRA Admin is required if you want to make any changes to post functions. 

Within every transition – there is a order that the operations occur:

Order of Operations

1) Conditions evaluated to see if user can use/see transition
2) Transition button is pressed
3) Screen is popped up (if set to)
4) Validators are checked
5) Issue is transitioned
6) Post functions are run

Now – the biggest request I get is to have JIRA make decisions in the workflow based of the issue of fields.  This is technically possible using conditions – it is not advised.  The reason why is this will lead to what’s called a “Spaghetti Workflow”, which is often confusing for end users, causes admin headaches when changes need to be made, and a in general leads to a lack of adoption. 

Termination – Resolution vs Status

If there is one thing I consider a cardinal sin within JIRA, it’s this:

This is an issue I see a lot, where teams will want to have multiple termination states to describe how it was closed.  This is not how JIRA is meant to be used. The idea is to assign a resolution describing how it was closed, and have a single termination state to show that it is closed.  JIRA, in fact, will not consider an issue closed until it has a resolution.  So when you are coming up with a workflow – please keep this in mind.