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

[#1]

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.

Adding a Jira Workflow Status

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. You need to decide how detailed you want your workflow to be.

Let’s say we’ve created 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? In general, before adding a 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?

  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, and 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?
  And if so, do the other projects need the new status as well? If you’re working 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 is what makes Jira scaleable. 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.

When to Create a Jira Subtask

If you’ve ruled out creating a new status, but you want to be able to see that all needed steps to carry out a task have been completed, then your options are to use subtasks, or checklists, or both (some checklist apps allow you to create issues/subtasks from checklist items). 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 in software projects. Currently, subtasks are visible in the backlog of Kanban boards (assuming the backlog is enabled), but not in the backlog of Scrum boards. 
  
  

  Then there’s the question of calculating time estimates or 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. Using a single issue with a checklist may be simpler.
  
  

• Do you want to log time spent on the step?
  If you want team members to log time spent on the step, then a subtask is a good solution.

Checklists – The Lightweight Solution

A checklist is a simple, but powerful solution to managing the multiple steps involved in completing a task.  You can create a simple checklist by creating a Jira custom checkbox field, or use a checklist app. (Note that I am part of the Issue Checklist for Jira team, but you can find several checklist apps in the Marketplace). Apps from the Marketplace may include some of the same features you get when using subtasks (user mentions, statuses, due dates, etc.) Either way, using checklists is a good way to keep your Jira instance from becoming cluttered. 

• Do team members collaborate on individual steps, or does everybody do the step(s) assigned to them?
  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.
  
  

• Do individual team members break their work down differently?
  If you’re using a checklist app, it may have a permission scheme, or allow anyone who has permission to create/edit issues to also create/edit the checklist. This can be great for accommodating different working styles. 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. The administrator takes responsibility for knowing how the team will work. Checklists shift this responsibility over to individual users.
  
  

• What if some items on your list warrant the creation of a new issue and others don’t?
  If you’re using a checklist app, you may be able to create a new issues from a checklist item. This gives you the best of both worlds. You can see the whole list of steps that need to completed on one issue, while also having a separate issue for recording the in-depth work that needs to be done.
  
  

  Since the simplest solution is usually the best, starting with a checklist is recommended. If it turns out that it doesn’t meet your needs, you configure your checklist to create subtasks for specific items, or convert to subtasks completely.