Best approach when many teams work over one story

[Ievgen Platonov]

Can somebody help with one question. I am wondering what is a correct approach in organising tasks in a backlog story if people that will do them are from different scrum teams? What do I mean by that.
For instance, there are 2 features for 2 diff teams, but in scope of each feature (backlog story) we have one task for DevOps guy that is from another, a third team. Should we have a DevOps task in each backlog stories (story per feature) or we need to have a separate story, that is in a third team which contains 2 DevOps tasks for each feature?
Thanks.

[G subramanyam]

If you ask me @Ievgen Platonov  I would say track the capacity of the team in confluence page along with the estimations against the assignee. When management asks, you can share that confluence page for reference. Tag all the relevant people in page.

Having said, their may be other best solution and let's wait to hear them out. Once you get an answer, do post in this thread for the benefit of others.

[Ievgen Platonov]

Yes, but since I am not so experienced in Jira and in Scrum processes I'd like to get a suggestion. There could be many cases when one member could participate in development on part time, like a Makeup man, DevOps, shared QA and so on. In such cases, how to make estimation session at the sprint beginning (if person in many teams), daily meetings and so on?

[G subramanyam]

Hi @Ievgen Platonov welcome to the Atlassian community.

If I understand your query correctly, this is the approach I would suggest:

From your experience of Sprints, you might have identified the person(s) who are working on one of your task or subtask to complete the user story. In this scenario, include that person(s) in your team's capacity (can be full time or part time availability). So, when ever they complete the task or subtask from your team's story, the Jira reports will reflect the efforts, completion of story as well assignees. This will project a good view to management as well internal teams in understanding the dependencies and possible impediments.

Stay safe and stay healthy.

[Ievgen Platonov]

Hi @G subramanyam 
That sounds sensible, but that person is from different team and he works over some small tasks (UX) is scope of a story that is in our team. And that fact actually creates some issues in communication, understanding of task progress and statues and as a result in planning our story. And I want to understand how to solve that problem.

[KAGITHALA BABU ANVESH]

Hello @Ievgen Platonov,

Did you tried creating sub-tasks for each. ?

If all are related to the same story, you can try Sub-tasks under the story.

Thanks,

Anvesh

[Ievgen Platonov]

Hi. Yes I tried and having a separate task in one sprint seems to me most convenient, but some colleagues think that it's not best.

[KAGITHALA BABU ANVESH]

if we have all story-related items as sub-tasks under it. it is easy to track and we can deliver the story with the most efficiency. 

[Ievgen Platonov]

An argument against it is that person who works over e.g. UIX task is from another team and that team has its own priorities, stories, capabilities and it's impossible to track used times, measure team capacity and guaranty story completion in our team.

[Jack Brickey]

First, I don’t equate a story to a feature generally. A story is something that should be able to be completed within a sprint (~2wks). If your features are very small and can be completed within a sprint then ok. Now regarding your question, you definitely want to have individual issues for each user’s task. You might have a single story and sub-tasks if they are to be completed within a sprint. Or, you could have separate stories and link as relates to.

[Ievgen Platonov]

Hi. Regarding my question. Yes, I could choose any of mentioned approaches, but I want to choose best one. I am asking because now, in my team, we have a separate front-end developer (from another team) that takes some UIX tasks. Those tasks are attached to a different story (all of that is during one single sprint). And we actually have kind of synchronization problem within a sprint. You know, some tasks there, some tasks here. We don't know progress and status of them. We need to check all of that manually. And we have a separate person to coordinate those processes. And personally I don't like that. And I want to change that.