nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

Nic Brough -Adaptavist-

Claudio Cherchi

Thank you. It's enough for our needs.

Regards,

Claudio

Janet Genusa_75wd6x

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?

rsteers

This is not supported

David Llewellyn_o1yd40

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! Cheers!

allanctodd

Seems like an ill thought out limitation and David has already explaine why.

Here's an example. My team needs a task to work on the back end, the UI team needs a task to work on the front end. Both need to be done to fulfil the user requirement.

Allie Stewart

We have the same situation. Of course we do, because it's a real life situation. I have Teams set up for UI/UX, Database, Development, QA, etc.. each of those Teams participates in the completion of a Story. Thus, they are sub-tasks to the Story. I have to be able to assign a different Team so that I can plan capacity appropriately.

The use of sub-tasks is vital easily, visually see, the status and progress of the parent ticket. Using linked tickets in this situation doesn't give us the status, progress and we cannot see linked tickets in Advanced Roadmaps. So it's useless.

Sub-tasks are the correct way to set up this ticket, assigning each step to the appropriate Team and being able to manage the tickets (parents and all) in Advanced Roadmaps.

This is a gigantic limitation of Jira that may actually push off of the platform.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud