Assign Team to Sub-Task on Advanced Roadmap Plan

[Matt Steadman]

Reading through the documentation on Advanced Roadmaps, it looks like the intended use is to only be able to assign a Team to the Story. Is there any way anyone has found to be able to have a Team assigned to a Sub-Task of a Story? We have a use case where the Story Issue is a main idea and the Sub-Tasks of that Story would be intended for different Teams to accomplish a piece of work on that. Thanks for any response ahead of time.

[Nic Brough _Adaptavist_ · Accepted solution]

I think you're really going to struggle with this one.

Sub-tasks are not independent items outside their parent story, they are very much a part of a story.  A story should be worked on by one team, not several. 

Sub-tasks are there for breaking up stories into smaller parts so you can assign different team members, or use them for actions in different parts of a product or different technologies or whatever. 

But as they're part of the main story, some of their attributes have to be that of their parent.  Because if they were not, you could not call them part of their parent.  These attributes include sprints, versions, team allocated and so-on.

[Ivan Bezdenezhnih]

The problem is as follows: we're trying to plan front-end & back-end efforts on the project with using Auto Schedule. It works only based on the team's capacity and works great if we estimate user stories and assign them to some team. But the team is not cross-functional and front-end devs can't work on b/e stuff and vice versa. So we can plan and estimate only the specific sub-tasks which could be designated to specific teams with their own capacity, but that is impossible. Does that make sense?

[Melissa B]

I'm running into the same issue...

[Riccardo Ancona]

I am running into the same issue...

[suresh pareek]

same issue

[Ian Trimnell]

same here

[Nic Brough _Adaptavist_]

The issue here is with your processes and data structure, not the software.

You need to stop trying to use sub-tasks as work items in their own right, they are not issues themselves, they are parts of an issue.

[Ivan Bezdenezhnih]

Well, let's imagine that we need to implement a login form. We create a user story with acceptance criteria etc. In order to make it working we need to implement 2 sub-tasks:

- the front-end part of that form: markup, logic, tests etc (F/e team)

- The end-point: a model, a logic, tests etc (B/e team)

The criteria could be applied only to the entire login form, not to separate sub-tasks, hence we can't create the separate stories for end-point and the front-end application.

As long as sub-tasks could be only done by separate teams, we couldn't use Auto Schedule either.

What do you suggest in this specific case? @Nic Brough _Adaptavist_ 

[Nic Brough _Adaptavist_]

The two stories are not sub-tasks, they are stories in their own right, with a dependency on each other.   You say they need to be done by different teams, and that's one of the ways to define something as a separate story.

[Ivan Bezdenezhnih]

well, the back-end part of the login functionality couldn't be a separate story. It doesn't add any increment in terms of end user functionality. It's a technical task only. @Nic Brough _Adaptavist_ 

[Nic Brough _Adaptavist_]

But you've decided it is a story in its own right.

[Ivan Bezdenezhnih]

No, I have not. Why do you think so? Just the back-end task couldn't have been done by the front-end developers as long as they don't have the respective skills.

[Nic Brough _Adaptavist_]

Yes, you did, you stated that it is something that needs to be done by another team from the front-end story.

[Chad Nuesmeyer]

@Nic Brough _Adaptavist_ 
Our use case is different but, rooted in the same problem. We have multiple teams sharing a board. Boards are created to filter by Team.

When in QA, if an issue is discovered we would like to keep the main ticket in the QA Swimlane and send a subtask back to TODO. This gives us the ability to track how many iterations happened between Engg and QA on a particular ticket. It also provides a visual queue to the Engg on the type of work assigned to them in the TODO column.

Totally fine, to have the primary engineer that did the work, stay assigned to it.

All that said, we can't assign a team on a subtask, therefore, they are being filtered off of our boards.

[Nic Brough _Adaptavist_]

Boards are intended to represent a team's work, they're not intended for multiple teams (other than for other teams to see what a specific team is working on and how it is going).

There's no problem with what you're doing here, but you need to re-think your not-scrum process if you want it to be shown to you usefully in a scrum tool.

[Victor]

 @Matt Steadman  and @Lukasz LinczewskiI read on another thread today and some one proposed a solution you might want to try.

1) Creating two different user stories for the same task

2) Assign  the two user stories to the two different teams in question

3) Link the user story that is acting as a sub-task to the main task to the main task with a block.

4) Make sure which ever team or team member is handling the main task can not close the main task without the second user story (sub-task) being completed.

I think this could work as a work around.

[AntonGolikov]

I've also requested this feature. I think that the idea behind the current product is too theoretical. For sure there is a chance to create separate stories for each team, but:

a) story is a logical part of the product - a feature useful for users. As a product owner, I want to keep this logic while creating the backlog. I don't really want to create separate stories for backend and frontend, UX and QA, etc. to deliver the feature. It will just overcomplicate the backlog and planning. I want to have one item in the backlog - the feature I want to be added to the product, rest can be created as sub-tasks (to have the needed level of details of the work to be done to deliver the story/feature)

b) I want to see the whole effort spent on the story delivery. The time spent on the sub-tasks of a story is automatically aggregated (it's exactly what is expected). But if I need to create separate stories for the same feature then I'll need to calculate this effort manually. What is the feature if it's not a story? Seems that epic is something bigger than a single feature (that should be represented as a story).

[Michelle Hummel]

Same issue.  I understand the approach for why the Advanced Roadmap was designed this way but it still renders it useless for team capacity planning in my organization at this time.  I vote for Jira to address this limitation as a way to provide a more flexible tool for hybrid organizations not able to define "teams' and plan work at the sub-task level in this way. 

[Nic Brough _Adaptavist_]

There is no issue in the software, it's not a limitation. 

As discussed in the conversation attached to the answer, sub-tasks are part of their stories, not independent work items.

[Lukasz Linczewski]

@Matt Steadman we have a similar case. Do you mind sharing your final solution for that?

[Matt Steadman]

Unfortunately I never found a solution for this