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.
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.
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?
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_
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.
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.
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.
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).
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.