Team Field not editable in Sub-tasks

[Claudio Cherchi]

Hi everyone,
While working with the team field I discovered that it is not editable in sub-tasks items.
Is there a reason why this is not possible?

In addition, the field is blocked and I cannot make any modification regarding the context.
We are using Jira Cloud and the Advanced roadmap and the usage of the Team Field is helpful for filtering.

Suggestion or opinions are more than welcome.

Regards,

Claudio

[Nic Brough -Adaptavist- · Accepted solution]

A sub-task is a part of its parent issue, not a separate issue.  So if an issue "belongs" to a team, logically, any sub-tasks of it do as well, because they're a part of the issue.  So you can't edit the team.

[Claudio Cherchi]

Thank you. It's enough for our needs. 

Regards,

Claudio

[Janet Genusa]

Wouldn't it be a good feature to allow sub-tasks to assigned outside of the team that owns the parent?

[Nic Brough -Adaptavist-]

No.

A sub-task is entirely a part of its containing issue.  Why would you assign a different team to part of an item that needs to be done by the current team?

[Angelia Lee]

sometimes you do need to reassign sub-tasks to another squad within the same team.  it's not helpful at all to need to create new tasks when the work itself is part of the same Story

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

That's a good use of sub-tasks.  But it does not change the fact that sub-tasks are a fragment of their owning task.

[Angelia Lee]

Thanks for the shout out.  

Understand what you mean -- but it would be good not to have the tool dictate the way of working but facilitate it instead.   Hence, why i'd say this has been raised that many times -- and wonder why Atlassian is still strict in keeping to how this needs to work based on their understanding, and not the practicalities of delivery.

[David Exner]

I also agree with Angelina.

The sub-tasks owner (responsible team) is always the owner of the parent task (inheritance), but the executor can be someone else = a different team.

Creating another issue or custom field just because of this is rather additional work that increases complexity.

Why would it then make sense to be able to choose an assignee from a different team than from the one owning the task? :)

[Nic Brough -Adaptavist-]

Er, you can assign different people sub-tasks.

You can't assign a different team because the sub-task is part of an issue that already belongs to a specific team.   That's not what sub-tasks are for. 

When something should be done by a different team, you should have a story for the other team so they can handle it according to their process, and probably create a link to show that there is a dependency between the two stories.

[David Exner]

"Er, you can assign different people sub-tasks." <- I am not disputing this one. I am rather pointing out that even though the sub-task is owned by the team owning its parent issue, you can still assign a person from a different team (than from the one owning the parent issue/sub-task) to it.

Maybe my understanding of team vs assignee is limited. I thought tasks that are assigned to a specific team should be then processed by the team members of such a team.

Thank you for your support!

[Angelia Lee]

Yes - you can assign it to another team member -- but the issue then is that it will NOT appear on their Kanban board.  Rather it will show up in the existing parent Team Kanban with the assignee to the sub-task who's NOT from the same team, and also cannot view this ticket on their own team Kanban.

It's the practical usage for the tool where the details throws up such nuances that do impact on ways of working.

[Dan Hills]

I find it frustrating that Jira keeps big-brothering me.  Why do they believe that their way of engineering is the only way of doing engineering?  We want to use sub-tasks for collaboration.  It seems silly to create 2 different tasks to work on the same issue together.  e.g.  I need help with this issue from another team.  How are we supposed to do reviews that include more than one person?

[David Llewellyn]

IMO there is a problem with the above responses RE: not allowing sub-tasks to independently select teams from their parent issue:

1. Story issues capture a user-story, and in an agile methodology the story must provide value to the user. e.g. stories do not decompose into smaller stories unless each still delivers some value to the end user.

2. Often, multiple teams must collaborate to deliver the end-user value required by a story. This involves multiple teams planning their work and adding their work as child issues of the story.

IMO it does not make sense to assign teams to Story issues, because user-stories are points of collaboration that describe _WHAT_ a product must deliver, but _HOW_ that must be delivered often spans multiple teams. I find it rare that stories decompose to a single team whilst still delivering end-user value.

3. On Jira story issues, the default child issue type is a sub-task, which as pointed out above does not allow selection of a team.

Is the problem here that when collaborating around a story, the child issue type created by each team should be task type, and not sub-tasks?

If so, why is the default child issue type on a story sub-tasks?

Please make it make sense! :D Cheers!

[rsteers]

This is not supported