JIRA workflow configuration tips, explanation & examples
Welcome! You’ve probably worked with JIRA and it’s workflows because you’ve opened this medium post :)
After managing JIRA for more than five years in three different large IT companies I came to certain conclusions, that I would love to share with you:
Everyone hates configuring JIRA
Creating a workflow seems a very simple thing to do… at least at first. Only after a couple of months, when you need to do something a bit more custom, you will realize there is not only workflows but some things as workflow schemes, transitions, issue screens, resolutions, issue configuration schemes and so much more stuff you never saw before.
That can be very confusing if you do not know how it‘s connected all together
Usually, when the company is buying a new tool, they do not make extra efforts on how to set it up properly, so later on, it causes a lot of pain to modify /adjust.
I’m pretty sure, you’ve been in this situation — “Aaaah, screw it! Going to give permission to transition whatever they want”
To say it and share the links with Atlassian documentation is the simplest thing to do, but that’s not why you are here, right?
Below, I’ll show our examples and cases on how all this magic is used, with explanations on why!
By default, JIRA will propose you to select from one of the offered workflows, that most of the organizations use and later on have tons of problems when they want to customize it to properly.
So, later on, you might end up in a situation like in the image below — hundreds of identical workflows, with different names, without a possibility to simply delete it, while assigned to project if not using paid add-ons should be cleared one by one. Sounds “fun”, eh?
The biggest mess I've seen was 148 different projects with workflow setup like this. And believe me, you don't want to groom it afterward :)
In order to avoid that, you should use “Shared configuration” option with your already used workflows instead.
Use multiple workflows for different projects and clients
For us, as a rather small company, three separate workflows is more than enough. Below I will share the examples of what we use and explanations on why:
1. Three step workflow or Simplified Jira workflow.
Works best for very small teams (1–2 people) or the very start of a project. It’s perfect for the investigation projects or trying out new things as a team.
The main idea — do stuff, it doesn’t require any planning or testing. Just perfect and simple for small goals.
Pros:
- Simple
- Fast
Cons:
- Works for self-initiatives
- Not suitable for real project process
2. Simplified workflow (medium workflow)
Perfect for Support and Kanban projects. Where is only one QA specialist on your side assigned or a client reviews and tests tasks by himself (yes… this is still a thing in 2018…) :)
The main idea, is to add extra people and transitions, as client reviews or tests, constant iterations in working with ”To Do” (Backlog) and returning tickets to it.
Also can have different variations, for example status “Open”, that somebody has to prepare, rework the ticket/user story for developers to be understandable and check if all the assets are there, is it ready to be picked up by programmers.
3. Big project workflow
Perfect for projects that last more than two months, with many people from various departments available. It will require strict and structured ticket flow.
Usually goes along with Sprints and Fixed version, so it’s transparent on a timeline as well as with statuses on a Board.
Strict regulation on how tickets are progressed. You can't cut the corner or silently make issue to “Done” or something like that. The workflow will not allow you to do that.
Pros:
- Structured backlog, ticket flow
- All tickets return to “Backlog” if something is not right.
- Hard to make a mistake
- Better overview of Sprint/ Whole project
Cons:
- Need to follow the process
- More steps
Don’t let developers cut the corner
We all are lazy. And developers especially (that’s actually what they are paid for :) making life easier with automation of some sort).
We had a case when developers were just moving tickets to status “blocked” (when an issue can’t be processed due to the client, missing info, lack of assets, etc.) with forgetting to put a comment and mentioning a person on who’s department it’s blocked.
It’s a natural thing for every person — to get rid of a problem, you move it from yourself and your status “In Progress” to elsewhere, so it’s not bothering you anymore.
However, to prevent that, I just implemented an issue screen on a transition to status “Blocked”, so now, it’s a malicious act if you do not put a comment and assignee (since you see the popup of a message and have to make an action to close it without input). Most of the people will not be breaking the rule, if they know that they are breaking it and someone will notice, so one simple step! Solved our problem entirely :)
Transition Screens and required fields. (With our examples)
Maybe you’ve noticed — On each transition there are multiple extra options for making actions in JIRA.
Properties
It’s something I’ve never used before but would be really careful on that configuration since that can affect your whole JIRA setup.
Here is the manual on what you can do:
All possible ways on how you can modify JIRA workflows with properties:
Triggers
Personally, I didn’t configure that particular part, but I know it‘s very useful with BitBucket and GitHub for developers, so they can focus on their tool (IDE) and code, without manual work of moving ticket to “In progress” / “Code review”, etc.
My piece of advise, do not do it yourself, ask a colleague who is a programmer, so he will make sure that all the triggers are setup correct + he will advise you some of the extra steps while helping you.
Validators
I recommend to use this feature, it’s great for “creating a habit”
The best example (if “Time logged” = 0) then you would not be able to transition issue to next status. As a reminder, to input your logged hours first.
How we use it:
“Original estimate” field on transition from Backlog to In Progress should be set. Otherwise it will not allow you to make a transition and start working on issue. It helps to maintain order and make sure, that even if someone forgot to put estimate or Story points, condition property will help to prevent that.
Post Functions (!)
This is the one we really must mention as it will ruin your search queries and filters if forgot or left out.
Whenever making a new workflow, make sure you’ve set a flag and resolution for all your tickets. JIRA has two statuses “Done”. One is for the board itself (showing that ticket is done within a board).
We need to add a post function “Update field: Resolution — Done” and your issues will become “Done” in all the queries and filters.
Conditions
Basically, it’s checking if the Value is correct, before allowing you to transition issue further on.
Personally, I didn’t find some use cases that might help us with the work, maybe anyone of you have an experience with that?
That’s basically it about the workflows and how we use them. If there are any questions or suggestions, feel free to drop a comment!
Also, you are very welcome to share your JIRA workflow configuration best practises, tips and tricks!
May there be no blockers in your JIRA board :)
-Vyacheslav
Receive a new Mobile development related stories first. — Hit that follow button
Twitter: @ChiliLabs