Using of subtasks - Good or bad

Eran Malovany_h5o31q

Hello, 

Working to build a new Jira instance, and at the point i need to define my hierarchy.

My scenarios is:

- One jira project

- Multiple development teams.

- A user story in some cases should be execute by multiple teams.

 

The out of the box issue type definition in jira tell you to use:

Epic -> Story -> Sub tasks

Epic will be aggregation of a bigger functionality that can be divide into multiple user stories (from end user perspective), and stories will be divided to multiple technical sub-tasks for developers execution 

if this is the case what is the best way to represent it on the teams boards? assuming sub tasks should be split across multiple teams? or the idea is that story should be execute by the same team.

in addition sub tasks do not appear in the backlog, so what is the best way to manage it from capacity planning, time estimation etc..

 

Or it's better to have custom use of the issue types

Epic -> Story

with no sub tasks, Epic will be the actual Story from end user perspective,  divided to multiple technical user stories, which i can see in the backlog and assign to the relevant team

 

Your feedback is welcome

Thanks in advance.

Eran

Nic Brough -Adaptavist-

I would avoid the use of sub-tasks for team allocations.  Jira Software is mostly intended to support Agile, where it would be the Story that is dealt with by a single team (sub-tasks help the team break up the work that needs doing on the story, maybe for indicating a specific component or technology, or saying which member of the team is going to do that bit).

Sub-tasks do not appear in the backlog because they are useless noise in a backlog - as they are a part of their story, not an independent issue, you can't rank them (outside their story),  you can't put them into a team's sprint (they go into the sprint their parent is in, as part of it), and you can't do sprint estimates on them.  There's no reason to see them in a backlog, they have nothing to do with your sprint planning, or backlog refinement.

But you won't break anything by doing it.

Your problem is actually going to be that you need to give the story to multiple teams.  You're going to need to include the issue on many boards, and hence put it into different sprints for different teams.

A better way to do this is to split and link issues - when a story needs three separate teams to work on it, create a story for each team, link them together and then allocate them into the teams backlogs separately.