How can I set Story's default child issue type for a team-managed project?

David Llewellyn October 3, 2024

Hi,

 

I'd like to change a `Story` issues' default child issue type to a `Task` issue.

How can I achieve this in a team-managed project please?

 

Any help would be appreciated, thanks.

2 answers

2 votes
Shreeja J
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 3, 2024

Hello @David Llewellyn 

In team-managed projects, it’s not possible to change the default child issue type for a Story. You will need to manually create Task issues under a Story using the "Add issue type" option in the issue types.

Currently, there’s no option to set Task as the default child type, but you can share feedback with Atlassian to suggest this feature.

Thanks,
Shreeja J

0 votes
Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 3, 2024

Hello @David Llewellyn 

Welcome to the Atlassian community.

The issue type hierarchy in Team Managed projects is:

Epic (level 1)
|-- standard level issues (level 0) - i.e. Story, Task, Bug
|-- subtask level issues (level -1)

When creating the Child issues, you can create those children only as issues type from the level directly below the parent. In the case of a Story issue type, the child issues can be of the type(s) specified at level -1. Issues of the types at the same level as Story (level 0) cannot be created as Child issues of Story.

There is a limitation in Team Managed projects specifically only one issue type is permitted currently at the subtask level (level -1). You could rename the existing issue type from Subtask to something else (that is not already used for another issue type in that project), but you cannot add more issue types at level -1.

David Llewellyn October 7, 2024

Hi @Trudy Claspill 

Thank you very much for your detailed response. This is what I had guessed and feared!

I feel like this contradicts the obvious / typical way to work on agile stories. e.g. story issues typically capture literal stories of the form:

as a [persona] I want to [perform action] so that [desired outcome].

in other words, stories typically describe _what_ value should be delivered, but not _how_ which often requires work across multiple teams.

As sub-task issues cannot have a team field set (independently of their parent) and stories only permit sub-task child issues, this means that the only child issues permitted by a story unfortunately cannot be distinguished by team.

In my experience, it is rare that delivering the value within a story can be achieved by a single team, and usually requires cross-team collaboration with the story being the focal point of the teams.

Adding child-issues to a story feels like the natural place teams would want to break-down their team specific tasks required to deliver the value described by the story ticket.

Assigning teams per story child issue (e.g. each sub-tasks) would allow better planning and focus e.g. by filtering team specific boards to display only relevant sub-tasks.

I have a couple of questions that spawn out of this:

- Is there an alternative opinion about this divide between stories and team specific work?

- Is there an alternative Jira workflow that deals with refining stories into tasks?

 

Thanks for the help! I appreciate it!

Like Walter Buggenhout likes this
Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 7, 2024

- Is there an alternative Jira workflow that deals with refining stories into tasks?

As I understand the design of Jira, the items at level 0 are intended to be scoped for completion within a Sprint (if you are using scrum). Items at level 0 are the ones that are recognized in burndown/up charts. I can't hypothesize on why Atlassian made this design decision decades ago when they started developing the product.

Having multiple levels of issue type hierarchy below level 0 would require a major redesign and re-implementation of a significant portion of the product functionality I suspect.

If your User Story scope can't be completed within a sprint then perhaps it would be better to use the Epic issue type instead of the Story issue type to create your User Stories. With the Jira Premium subscription, or with third party apps, it is possible to extend the issue type hierarchy above the Epic level if you need additional parent/child relationships. (Note that currently in Team Managed project you cannot directly extend the hierarchy. The additional levels/issue types exist in Company Managed projects, and your TM Project Epic can be made of child of the issue in the Company Managed project.)

A native Jira alternative is to use generic Issue Linking to link your "child" Task type issues to their "parent" Story type issues. Jira will not see that as a parent/child relationship and will not automatically apply any parent/child functionality to issues, such as showing them in a hierarchical view or rolling up progress/work-logs from the "child" to the "parent".

You could also consider third party apps that integrate with Jira that might give you more flexibility with the issue type hierarchy.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events