When to use Task in Jira - a practical approach for development teams

One of the most common questions I get is when to use the issue type Task in Jira. This is not surprising since Jira is intentionally not defining how to use the issue types and their hierarchy. This is to avoid restricting the users from building a way of working that is best suited for them. In this article I will explain my thoughts from a development perspective.

As I have described before in the article "Setup Jira and Confluence for success - Part 2: Defining Jira Issue Types" there are three levels in the standard Jira hierarchy. Task would fall into the middle level and the sub-tasks would be the last level. This means that Task would be on the same level as a Story and that is what we can start from when defining what should a Task be for in a development perspective.

In a normal workflow for development we would have a Story issue created as a result from the requirement, or need if working Agile, process. So the Story would map towards a need or requirement and as such we would have a workflow where we can trace actions from idea all the way to production.

Then where do Task fit into that workflow?

In most cases it will not as a task would not be a part of a requirement or a need. That is what a Story is for. A Task is most likely only going to be used for Task management rather than as a workflow. This means that a Task would most likely be something that have limited states such as New, In Progress and Closed. It might even just have New and Closed to be even closer to the way task management is defined.

In a development situation where you need to have a workflow a Task is best suited for activities that are not directly related to the workflow. Things like setting up environments, prepare presentations or Demos and even things like buying cake for the next retrospective (which of course always is mandatory!).

If you use Tasks in this way, then sub-tasks would follow the same pattern. For a development task for example you might need to schedule a meeting with an external vendor to go over the API details for an integration. For a test task you might need to organize a workshop for end to end testing across multiple teams and systems and so on.

In short, my definition is that Tasks are used for internal task management that is not directly related to the workflow.

Do you agree or disagree?