How do you handle subtasks tickets in boards ?

Question

Hello,

I would like to know how you handle subtasks tickets in your boards.

We create Stories and these stories are divided into technical subtasks (front, back, api doc...).

We have two boards with different workflows:

- Product board, that displays parents tickets: Stories, Bugs, Tasks - with the following workflow: to do, in progress, next staging (review), bugged, test, ready

- Dev board, that displayed tickets with Stories as Swimlanes, so subtasks are directly displayed - with the following workflow: to do, dev, review, merged

Subtasks have a different workflows as other tickets, so they are not displayed in the product board.

My issue is that I have to create at least one subtask to a ticket to be handle by a developer, even for bug or task ticket.

It doesn't make a lot of sense to me as the parent ticket and the subtasks are the same, and it takes time to put twice the right tag, right priority...

As a PM I need to have the Stories vision (with only parents tickets: Stories, Bugs, Tasks).

Developers need to have the subtasks vision so they know easily on what they have to work.

What do you recommand ? Have do you handle the situation in your team ?

Thanks in advance for your help.

Justine Leurent · Answer

Hi @Rachel Wright

Thanks a lot for you reply and for sharing the way you handle tickets.

I actually don't want to create subtasks for bugs. But if I don't do it, developers are not able to handle the bugs tickets in their board as their board manages subtasks only.

The reason why we have different statuses for subtasks and parent tickets is that I don't want to have all subtasks displayed on my product board.

I create US and then developers create subtasks to divide the work between them (front, back, api doc...).

Here is an example of a ticket to list an element, that is divided in different subtasks for devs. On my the product board, it is only one ticket In progress.

Do you have any recommandation ?

Thanks again for your reply.

Justine

Rachel Wright · Answer

Hi @Justine Leurent ,

I only create Sub-tasks under the following conditions:

* The parent issue (Ex: Story, Task, etc) is very large and needs to broken down into manageable pieces
* Parts of the parent issue will be worked or released at different times
* Different people will work on different parts of the parent issue

You're right, it does create an extra step and extra diligence, to make sure the dates and other fields are correct in any Sub-tasks.

If a parent issue is simple and straight-forward, I don't bother creating additional Sub-tasks.

I generally don't create Sub-tasks for Bugs, although I have seen companies do it.

Often I see this model:  A Project Manager or Project Owner type of person creates the parent issues, and the Dev team creates and manages any Sub-tasks they need to fulfill the request.

I don't think there's a super "right" or super "wrong" way to do it.  It's just important that whatever method you use makes sense for your teams and expectations are understood by everyone.

Hope this helps and if not, hopefully someone else from the community with share their opinions!

Rachel Wright
Author, Jira Strategy Admin Workbook