JIRA’s workflow engine provides a powerful tool for managing and monitoring the work that you and your teams are doing. By tracking the status of tasks, stories, epics, and initiatives, you can improve certainty, reduce or eliminate status update meetings, and build in automation and controls at each status transition. But when a company begins using JIRA for the first time, they sometimes make the mistake of over-complicating their workflow. You want to get fine-grained visibility into the status of work, but building a workflow with twenty or thirty statuses results in a workflow nobody wants to use. A better approach is to start with a simple workflow, and add statuses when you need them.
But how do you know when you will need a new status? I have a couple of rules that help me make workflows that people like to use, and when people enjoy using them, they’re more likely to keep the ticket updated, which means your data is more accurate and actually useful.
How does the team think about their work?
One of the common problems I see in overly complex workflows is that the vast number of statuses don’t actually reflect how people do their work. Let’s look at an example of a sales person who receives a phone call asking for the price of a product. The company wants all inbound phone calls logged in JIRA, so the sales person creates a Task issue and logs the caller’s details and their question. Next, they’re going to locate the product in the registry, identify the market price, then research whether or not the caller gets a discount. If the caller is from a company that receives a discount, the sales person will need to look up that discount, calculate the new price, then communicate that back to the caller.
Management might be interested to know how long it is taking to identify that a customer gets a discount and then provide that information, so it wouldn’t be irrational to create the following statuses in the workflow:
The problem with this is that, for the sales person, steps 2-5 all happen within a few minutes, and during those minutes they’re busy helping the customer! People aren’t generally going to bother clicking through statuses when each step takes a few seconds or minutes to complete.
I have encountered numerous workflows over the years that get over-tooled this way. In reality, steps 2-5 for the sales person could be boiled down to “In Progress.” If management really wants to know how long it takes to identify a discount, this method of tracking won’t get them that information because people aren’t going to click the buttons while they’re busy. You’ll end up with tickets sitting in Open for a long time, and every other status lasting for only the one second it takes to click the button.
For the curious, in this case I would recommend that management record phone calls, identify which ones involve discounts (maybe through a checkbox or select list custom field on JIRA), then listen to the call and use a stopwatch. You can better identify training opportunities that way, while also getting accurate information about what you want to learn.
We can all identify dozens of discrete steps in the tasks we do at work, but it is rare that these steps need to become JIRA workflow statuses. Instead of creating a status to track a step, you should create one to facilitate handing the work to someone else.
When is work handed off to someone else? And what can I automate?
A perfect opportunity for a new status is when work needs to be re-assigned. Sometimes, assignment happen within the standard “In Progress” status, but whenever work needs to go somewhere else, that generally indicates that something different needs to be done with it. Reporting on those different types of work can be really helpful. I usually partner this advice with, “You should create a new status if the next piece of work that needs done is both different and will take a long time.” Per our example above, no one will change a status if just a few minutes are needed, but if it’s going to be hours or days, then there’s a reasonable expectation that the status be updated.
If your status transitions include re-assigning the issue, the very least amount of automation you should do is a notification to the new assignee. They need to know that a new piece of work has come to their inbox. But if the assignee is the same person for that status every time, you can also automate the assignment on the transition using a post function. Think about the manual actions you take during each transition and see if you can automate any of them using JIRA. And don’t forget that add-ons like ScriptRunner and JIRA Misc Workflow Extensions can provide some powerful post functions to improve your work.
A good rule of thumb when designing JIRA configurations is that the tool should make your job easier. You shouldn’t be working to make the tool work, you should be working on the stuff that needs done. Let JIRA do as much of the work management and reporting as possible so you can focus on the important stuff of supporting your customers and team members.
Does this provide data to drive decision-making?
In our earlier example, management was trying to figure out how long it was taking to provide discount information to customers. That might be an important metric to measure and improve on, but trying to use JIRA workflow statuses to derive that metric wasn’t going to work. Whenever we change or add to a configuration in JIRA, we need to ask ourselves why we’re doing it. Are we trying to make our jobs easier, or are we trying to get more data for reporting? If our goal is to improve reporting, then our next question needs to be: will this data help us to make better decisions?
I love data. I love charts and gadgets and spreadsheets and just looking at stuff to gain a more comprehensive understanding of the work being done. But to get more data for reporting, you have to collect more data, and in many cases with JIRA that data is going to be manually entered by your team. This manual entry has an impact on other work, and it can also be really annoying to do.
It is important that we really think through a request for more data. Will that data help us make better decisions? Will it further our mission? Will it enable us to help our customers better? And last, will the proposed change in JIRA be the best way to get that data, or is there a better way we should think about?
Don’t gather data for the sake of data. All that will accomplish is slowing down work and negatively impacting the outcomes of your team. Again, the tool should be making work better, not worse, so think through this before over-complicating your workflow.
I like the basic To Do, In Progress, Done approach that Atlassian has standardized on, but I also find that I typically need a few more statuses than that. It is rare that I design a workflow with more than 7 statuses these days, unless I’m working on complex change management, or a shared workflow where different phases will be used by different teams. Advanced workflows will have to be part of a different blog post, though, so stay tuned!