It’s awesome when one tool can be used for multiple purposes. Jira workflows are no exception. There are a few reasons you should try to limit the number of workflows used within your organization. The first is simplicity. Fewer workflows will make your Jira instance less complicated to manage. A less complicated Jira instance has a good chance of being a better used, better performing Jira instance.
Note: This article is one in a series written in collaboration with Rachel Wright, author of the Jira Strategy Admin Workbook. See the bottom of this post for links to the other articles in the series.
Fewer workflows also makes life easier for your teams’ customers. As you start bringing more and more business teams into Jira you’ll notice that a lot of processes involve more than one team. Think about employee onboarding. HR does the heavy lifting by processing reams of paperwork- getting bank details and emergency contact information, ensuring that the new employee has legal working status, setting them up for (sigh) appropriate tax withholdings. But HR is not the only team involved. Your new employee will also need a place to work, a name badge, a key to the building. After Operations has provided those things, they’ll need IT to set them up with a computer, an email account, and access to the appropriate networks.
Having multiple teams use the same workflow means you can pass requests (move issues) from one team to another. Therefore, rather than the hiring supervisor having to submit three different requests to onboard their new employee, they could submit one.
So, let’s take a look at a few of the most common workflows and think about how they could function for different teams.
Project Management Jira Workflow
Process Management Jira Workflow
The above are two of the most common workflows. In both cases, work is moved from an “Open” or “To Do” status to a “Done” status. The difference is that the Process Management workflow requires an approval.
A whole lot could get done using just these two workflows. An important thing to remember is that the same status can mean different things to different teams. Take the “Done” status that we use for issues that have been resolved. For a Marketing team creating content “done” may mean published. For a Procurement team “done” may mean purchased. Those differences do not mean they can't use the same workflow.
Document Approval Jira Workflow
Now let’s look at a couple more workflows you might want to have in your collection. Atlassian offers a Document Approval workflow that looks like this:
There are two important differences between this workflow and the Process Management workflow: 1) The Document Approval workflow has statuses for two separate reviews before the item in question, in this case a document, is approved; and 2) There’s no option to cancel - this is a process that has to be completed, the only question is how.
Again, there’s no reason this workflow has to be limited to documents. Change “Draft” to “In Progress” and you have a workflow that could work for any number of processes.
Finally, let’s look at this one which was included in an Atlassian blog post entitled Marketing project management with Jira Core. This workflow was designed for managing the publication of blog posts:
The interesting thing here that “approval” is not the end of the road. Even after the content has been approved, someone still has to load the article into your blog, set key words, schedule the post to go live, etc.
If the statuses in this workflow were given more generic names, it could be used for other processes - for instance, contract management. Several iterations (from draft to review and back again) may be needed before the contract is actually approved. It needs to be executed (add web tasks) and then needs to be complied with while the contract period is open. Finally, when the contract is complete it can be filed away as “done”.
There may be times when these basic workflows won’t fit a process, or even times when you need to create a custom workflow, but embracing a strategy of simplicity with regards to workflows will not be limiting, in fact you may find it quite liberating.
Other articles in this series:
- Who’s in Charge? Jira Governance for Business Teams
- System, Application & Project Admins: Who Does What in Jira?