The great thing about Jira is that it’s almost infinitely flexible – teams can manage their work the way they want. It also means teams have to make some decisions, including how they want to handle the mini-steps that need to be completed in order to resolve an issue. These steps can be built into the workflow as additional statues, broken down into subtasks, or included as items on a checklist on the Jira work item. Each solution has advantages and disadvantages.
When to Use a Jira Workflow Status rather than a Jira Subtask or Checklist?
Since a workflow is a map of the steps a work item goes through on the way to completion, it’’s logical that there should be a workflow status for each step. Following that however, can mean your workflow quickly gets overly complicated. You need to decide how granualar you want your Jira workflow to be.
Let’s say you have a “Feature” work type. In order to create a new feature, you’ll gather requirements and determine scope, build the feature, review the code, test (and iterate through the process again depending on the test results), deploy the feature and then close the Jira work item.
Your workflow might look like this:
That workflow will work just fine, but consider how much more complex it is than the Software Simplified Workflow:
Since the simplified workflow above is often used for software development, does your new Feature work type really need a more complex workflow?
Before adding a new status to a workflow, you should consider:
- Will an additional status make the workflow overly complex?
Simple workflows are more flexible and easier for users to understand. Many experts say that a workflow should have no more than seven statuses (I’ve occasionally stretched the no-more-than-7 rule to 9, but it’s a best to keep the workflow as simple as possible). - Do you need to query or report on work items in this status?
This is a good litmus test for adding a new status (and probably for other things in Jira). If the answer is no, it’s a good indication that the step does not need its own status. - Are the steps mutually exclusive?
A Jira work item can only be in one status at a time. A workflow reflects the typical order that the items will pass through those statuses. If more than one step can/should be worked on at the same time, then they should not be separate statuses. - Is the workflow shared by other projects?
If so, do the other projects need the new status as well? In Company Managed Projects it’s important to consider how changes to the workflow will impact other projects. Sharing assets across multiple projects makes Jira scaleable, but it also means you have to be careful when making changes. A workflow that is overly specific, with statuses to represent all of the small steps in the work item lifecycle, may not be generic enough to fit for multiple projects. Err on the side of simplicity.
When to Use a Jira Subtask rather than a Jira Status or Checklist?
If you’ve ruled out creating a new status, but you want to be able to see a detailed list of each step needed to complete the work item, consider using subtasks or checklists, or both.
Atlassian has recently improved how subtasks look and work in Jira. The panel displaying subtasks now lets you:
- Configure which columns are displayed
- Edit fields inline
- Bulk edit
- Sort
- Hide completed items
- View items on the search page
The following use cases are good times to use a subtask:
- When the step requires collaboration
Will multiple team members be collaborating around a single step? Do they need to upload attachments for everyone to view and discuss? Will solutions be proposed and decided upon in the comments section? In this case, you’ll want a subtask to contain all of the needed input. - When you want to estimate and track time on the step
There’s also the question of how subtasks are handled for planning work and tracking time. - If you want to track time against each step, subtasks are good solution.
- Does the task need to be reviewed and/or approved by someone?
Since a subtask acts like a regular work item going the Jira workflow, it can be reviewed, approved, or sent back to a previous status to be reworked.
When to Use a Checklist rather than a Jira Subtask or New Jira Status
A checklist is a simple, but powerful solution to managing the multiple steps involved in completing a Jira work item. Using checklists in lieu of statuses or subtasks can help streamline your Jira instance. You can chose between a simple checklist, or enhance your list with many of the features you enjoy when using subtasks (user mentions, statuses, etc.).
So when is a checklist the best option?
Checklists vs Jira Subtask
- When you want to keep everyone focused on the entire story
Using a checklist on an work item keeps everyone “on the same page”. If you don’t need comments or attachments for individual steps, then stick with a checklist. This is the most open and transparent way to work. - When you want to empower everyone
By default, Checklists can be created/edited by anyone who has permission to edit the Jira item. Individuals can break their work down into whatever steps work for them. If Jan is happy with an outline of the big steps, but Jack likes a minute listing of everything, they can each tailor their checklists to meet their needs. If multiple team members are collaborating on a work item and one person wants more details for their items in the checklist, they can simply add the items they need, and mention themself.This highlights and important difference between checklists and the other two options. Workflow statuses and subtask work types are created by Jira Administrators, Team Leads, Scrum Masters, etc. The leader takes responsibility for knowing how the team will work. Checklists shift this responsibility over to individual users. - Will work on the item extend across multiple sprints?
Subtasks can be a pain if you want to split the steps that need to be done across more than one sprint. Checklists work well with sprints, allowing to list exactly the steps the plan you to complete in the timeframe of the sprint. - When you want to keep your board, or your backlog clean
Subtasks can complicate search and clog up your backlog. Checklists allow you to define and standardize processes without showing every step in every place. To avoid clutter, start with a checklist. You can expand checklist items into separate Jira work items later if you need to. - When you want to use Story points
If your team uses story points, Jira assumes that the number of story points will be recorded only on the parent work item (typically a Story). If you want to include story points on each subtasks with the total automatically shown on the parent item, you’ll need to set up automation. In this case, using a single Jira work item with a checklist may be simpler. - When you want to repeat the same steps on multiple work items
If you’re going to be using the same set of steps on multiple work items, you can easily create a checklist template which can be instantly applied to any work item.
But what if you’re not sure? Start with a checklist because it’s the simplest solution. If you change your mind, you can quickly convert an item to a new issue, or convert all incomplete checklist items into subtasks.
Checklists vs Jira Statuses
Since complex workflows can be confusing for users and add to administrative overload, avoid adding a new Jira status unless it’s really necessary.
However, if there is a whole set of mini-tasks that that need to be completed, and if you want to monitor how many Jira work items are in this phase – it may be worth creating a new status.
In this case, you can use Jira automation to replace the checklist, or append new checklist items as the work item moves through each status in the workflow.
Jira’s flexibility means you have a lot of options for how you structure your work. Choosing lightweight solutions can help keep your configuration simple, your users happy and your instance from becoming bloated.
