Status, Subtask or Checklist: How to Divide Work in Jira?

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 issue. Each solution has advantages and disadvantages.

When is a Jira Workflow Status Better than a Jira Subtask or Checklist?

Since a workflow is a map of the steps an issue goes through on the way to completion, then 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” issue type. In order to create a new feature, you’ll gather requirements and determine scope, build the feature, review the code, test (iterate through the process again depending on the test results), deploy the feature and then close the issue.

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 issue 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 issues 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 issue can only be in one status at a time. A workflow reflects the typical order that the issue 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 (Classic) than 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 an issue lifecycle, may not be generic enough to fit for multiple projects. Err on the side of simplicity.

When is a Jira Subtask Better than a New 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 issue, or checklists, or both. In deciding whether to use a subtask or a checklist, you should consider:

• Is collaboration needed?
  ‍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.
  
  
• How does your team plan and estimate their work?
  ‍‍There’s also the question of how subtasks are handled for planning work and tracking time. Currently, subtasks are visible in the backlog of Kanban boards (assuming the backlog is enabled), but not in the backlog of Scrum boards. So you need to decide if the step is important enough that you want to see it as a separate card on your board.  If you want to track time agains each step, subtasks are good solution.If your team uses story points, Jira assumes that the number of story points will be recorded only on the parent issue (typically a Story) . If you want to include story points on each subtasks with the total automatically shown on the parent issue, you’ll need to set up automation. In this case, using a single issue with a checklist may be simpler.
  
  

• Does the task need to be reviewed and/or approved by someone?
  Since a subtask acts like a regular issue going the Jira workflow, it can be reviewed, approved, or sent back to  a previous status to be reworked.  

When is a Checklist  Better 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 task. Using checklists in lieu of statuses or subtasks can help keep your Jira instance from becoming bloated.  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 issue keeps everyone “on the same page” – or in this case on the same issue. If you don’t need comments or attachments for particular items, then stick with a checklist. This is the most open and transparent way to work.
  
  
• When you want to empower everyone
  Checklists can be created/edited by anyone who has permission to edit the issue. 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 checklist to meet their needs. If multiple team members are collaborating on an issue 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 issue 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.
  
  

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 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 issues 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 issue moves through each status in the workflow.  

Jira’s flexibility means you have a lot of options for you structure your work. Choosing  lightweight solutions can help keep your configuration simple, your users happy and your instance from becoming bloated

‍