Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,295,594
Community Members
 
Community Events
165
Community Groups

Why are my sub-tasks hidden?

I have several teams working on different aspects of the same project. We are using one project, while each team has its own board. The boards are filtered using the Portfolio Shared Team field. For example, Team 20's filter looks like: project = MC AND Team = 20 while Team 21's filter looks like project = MC AND Team = 21.This means for every issue we create we need to specify the Team for it to appear in the correct board.

For some reason, sub-tasks of these Issues are hidden when viewing the Issues on the Board in the Backlog and Sprint views. They are only visible when viewing the Issue in browse mode. I want to be able to view and move the sub-tasks of the stories I have in the current sprint.

Why are the sub-tasks hidden?

2 answers

(update: subtasks that inherit Team[Team] from parent do show up in JQL query results)

Any progress on this since 2017?  

We are about to change everyone over from custom team fields to using Team[Team] - the Shared Teams specifically that can be created through Advanced Roadmaps.

As we bulk update to sync all the legacy values to the new Team[Team] field, the subtasks won't update.

image.png

If Sub-tasks are inheriting from their parents, shouldn't that value be able to be queried in JQL? 

(update: subtasks that inherit Team[Team] from parent do show up in JQL query results)

Also, reading this.... https://confluence.atlassian.com/jiraportfoliocloud/searching-for-portfolio-for-jira-custom-fields-in-jql-941619014.html 

image.png

 

It seems that subtasks should be coming through, just by using the Team name.

So does that mean that new subtasks created will get the value?  

FALSE ALARM.

Turns out all of this is actually working - the issue we have, is that some of our subtasks were assigned to a different team (our own custom Team[Dropdown] field, not Team[Team]).  

So, as we bulk update Team[Team] and convert boards, filters, etc, any subtasks that were assigned to a different team than their parents will disappear off those boards because the subtasks can only belong to parents if only filtering on Team[Team].

Pro: we know the query works

Con: cannot have subtasks assigned to different teams than the parent, while only using Team[Team].

Does anyone else have a need to have their subtasks belong to different teams, e.g. a QA team?  Not agile to have QA on a separate team from devs, we know, but it's where we are today.

0 votes

Because there is no point in them being visible in planning - you can't rank them outside the parent issue (it's of no use) and they follow their parent into and out of sprints.

I agree that they are useless in planning when viewing the team's product backlog, but they are very useful when viewing the team's sprint in situations like stand-up. Let's say we are in our daily stand-up and a developer wants to illustrate how far along she is in her story. She has the work broken into sub-tasks. Some of those tasks may even be assigned to another member of the team. I should be able to view the sub-tasks for a given story in the context of a sprint. We have done this on other projects that are not filtered by Team. Why does the Team field conflict with this, especially when the sub-task inherits the Team of it's parent?

In a stand-up, most look at the working board, where sub-tasks do appear.

I think I should apologise for skipping over the detail in the second part of your question.  Your filter is excluding them because the team does not appear to be being inherited as you think it is.

So, easy quesiton - is the Team field definitely appearing on the sub-tasks?  If not, then that would explain them not appearing on the board.

When I create a sub-task under a story with a given Team, the Team field is locked and in its place it reads "The team for a sub-task is inherited from the parent issue."

 

Oh, one of those fields.  Ok, we'll have to work around it.  Change the board filter to:

project = MC AND ( Team = 20 or issuetype in subtaskIssueTypes() )

That worked! However, now all sub-tasks across the entire project (not specific to a Team) are returned when I run that query; they don't appear in the backlog or working view which is good. Is there a way to change the query to only return the sub-tasks for the stories for a given Team?

I don't think there is, because it's a two-layer filter - you need to run it to get the parents, then another filter to get their child issues.

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you