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.

[Pierre Leroux]

Sorry to disagree @Nic Brough -Adaptavist- , but SCRUM teams are way better when they are multidisciplinary teams, focused on developing working pieces of software, not isolated work chunks, separated in silos. It's actually recommended by most SCRUM coaches to build teams that are autonomous in their feature development. In the gaming industry, scrum teams can sometimes be composed of 7 different disciplines, all working towards the same deliverable. In that extent, it's a fair request to think the organization in a Matrix way : there can be SCRUM teams, composed of persons from different disciplines, coexisting with DISCIPLINE teams. A single person can therefore be part of a SCRUM team, responsible for delivering a working piece of software, and also part of a DISCIPLINE team, composed of persons of a certain skill set, sharing their best practices. So, being able to assign subtasks to DISCIPLINE teams in addition for them to be part of a Sprint, would help anticipate the workload of groups of people of a specific disciplines. At the moment, I see no way to do that efficiently in JIRA Cloud except by using Epics for our user stories instead of Stories, which is kind of confusing. And the purpose of advanced roadmaps capacity planning is hindered by this limitation.

BTW, when I read "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.", sorry to disagree again: checklists are made for that purpose. Subtasks are here to spread the work between team members to realize a user story (often for an end user), and those team members do not necessary have the same skillset.

[Nic Brough -Adaptavist-]

No need to apologise, people opine differently

I agree with what you say on the surface, but it is clear that you do not understand Scrum.  You have not grasped the basics of Scrum task/issue/story.  Or how sub-tasks are fragments of a story.

[Pierre Leroux]

Thanks for you answer Nic Brough -Adaptavist-. I have been working as a product owner, scrum master and have worked with many, many scrum teams in different companies for about 20 years now. I humbly believe I know the basics of scrum pretty well, read reference books and got scrum trainings. But I can understand everyone makes mistakes. I will forgive your tone and move forward with constructive workarounds other community members have suggested to answer the need from vetted product owners and executives who would like to use Advanced Roadmaps to better forecast assignations of multi-disciplinary scrum teams over time.

[Nic Brough -Adaptavist-]

There are no "workarounds", your choice to do it differently simply means you are not quite doing Scrum.  And trying to use a Scrum tool to support a non-Scrum process is going to mean that you need to compromise.

[Pierre Leroux]

We do use scrum, most our team members and managers are certified and we tent to do it by the book, but maybe you did not have the time to ask questions before making your statement. Forecasting disciplines workload is a concern, as no company would want to pay someone who is 100% allocated to a scrum team and have nothing to do. An artist who won't code can still can be part of a scrum team that delivers game features where we have frontend developpers, and sometimes that person is not needed for a sprint, or is needed just 50%. Our current conclusion is: for anticipating assignation of specialists to multi-disciplinary scrum teams, maybe Advanced Roadmaps is not the right tool. Humility forward dear @Nic Brough -Adaptavist- .

[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).

[Pierre Leroux]

I cannot agree more with this @AntonGolikov and I am wondering if the current work on Teams is going to address this issue. It looks like at Atlassian, people are working only in single-discipline teams, which is not a very Agile way to work.

[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.

[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