Subtask workflows for Scrum

[Mara Julin]

Hi all,

I'm looking at potentially leveraging subtasks for our scrum teams to track different types of QA. Reason being, I've noticed how our board workflows can get messy and cumbersome because our QA tickets don't require all the statuses in the scrum board.

The only way for subtasks to be simpler is if they have a simpler workflow (e.g. to do --> in progress --> done) but I noticed that all our subtasks in our projects have the same workflow as the parent board.

Is this typical to match up workflows? Not sure if this is a legacy thing because no one configured it or if this is best practice. Thanks!

[Trudy Claspill]

Hello @Mara Julin 

Jira is highly configurable. The workflow assigned to issue types depends on what has been done to configure the workflows and workflow schemes. The workflow can be different for different issue types within a workflow scheme.

However when you are viewing issues with different workflows on one board, it can be confusing to understand which statuses/columns apply to which issue types. If you try to drag a card to a column that doesn't contain a Status that is applicable to that type of issue, the column will either appear disabled or the card will snap back to its starting point. That can confuse the user as there is not message to explain why the activity can't be completed.

Note that you don't have to switch your QA work to sub-tasks to give them a workflow that is different. You could create another Standard issue type (at the same level as Task/Story/Bug) for your QA work and configure a different workflow for that issue type.

If you switch to using sub-tasks to track your QA work, those sub-tasks will have to be children of another Standard issue type of issue on your board. That parent issue will also need a workflow, and that parent issue would not be considered Completed until all sub-tasks under it are completed. That would affect your metrics. Is that an impact you want to accept?

[Nic Brough -Adaptavist-]

It's not unusual to see the project only using one workflow, but it's perfectly possible to use different ones by issue type.  The "workflow scheme" for a project is the way Jira maps the workflow to the issue type - build your new workflow(s) (I recommend cheating -- copy and modify someone else's work, it's faster than starting clean), and associate them with your issue types.  Jira will walk you through a migration.

You will also need to consider the board columns - if you add status that are not already mapped on the board, then you'll need to map them. 

Of course, the important one is to get all the "needs no more attention from the team" status mapped into the last column on the board.