User stories which involve both back-end and front-end - who is the assignee?

[Jonathan Arad]

When creating requirements to a user story, in many cases it involves both front-end and back-end development resources.

What is the best practice?

1. separate user stories based on FE and BE teams?
2. who is assigned to a story with different sub-tasks which are assigned to different developers from different teams?

[Rodrigo Goncalves · Accepted solution]

Hi, if you allow me to weigh in ... the approach suggested here is exactly how I manage my projects, but it is hard to "train" or, should I say, "convince" the team to work flawlessly that way, mostly because we are all too busy to "enforce a process", not even spending time to "train" the people.

I also considered the option of having 2 different boards, one for FE and another one for BE and the tasks would be linked to each other when they had a dependency. Another benefit I see in this approach is to enforce the creation of "contracts" between FE and BE and once the contract is defined, both teams can work independently and delivered together following their inter-dependency ... But this is really "not agile" and quite more bureaucratic. So, I'm still using the "subtasks" assigned to different resources.

BUT, there is one big caveat that is really really painful and Jira team "insists" to say they don't accept the requirement (even though a lot of people ask for that). They claim that the requirement is not "agile" (that's how I understood from their responses ...).

The issue:

The issue is that we can't see the assigned subtasks in the backlog view in an Agile Board only in the "active sprint view" (although it is possible to show the indented subtasks and their assignment in the Kanban Board backlog view - which means the requirement is doable).

The consequence of that is that in the sprint planning meeting we don't know and we can't see the number of subtasks associated to the team, which can increase the scope of work "exponentially" and relies on my "feeling" to know all the work that is included all together when assigning tickets and planning the sprint.

I really would love that Jira could make it possible to configure (feature flag) to show indented subtasks in the Agile Board backlog view ... that would improve 100x the use of Jira.

Thanks!
Hope that help and someone in Jira team could see this request.

[Manuele Piastra]

Thanks! I agree that having subtasks visible in the backlog might be handy.

[Carlos Garcia Navarro · Accepted solution]

Hi Jonathan,

This may be a personal preference. In my opinion, the best is to create stories that can be traced to a requirement and that can fit in a sprint, and then to create sub-tasks to break down the work. I'd recommend to assign stories to a product owner or the person who is accountable for the work, while the developers are the assignees to the corresponding sub-tasks.

Hope this helps,

Carlos

[Manu]

Hi, thanks both. @Carlos Garcia Navarro , the approach that you describe is what we follow, but It creates some problems. For example: if we have the same story for iOS and Android, what we have in Jira is:

story1 (subtask for iOS, subtask for Backend)

story2 (subtask for Android, subtask for Backend, exactly the same as before)

as the two platform will use the same endpoints from the backend. So the backend subtask is the "problem". Do we keep two of them and then keep them constantly aligned? Do we keep one, for example under iOS, and then we link it from the Android story? This second approach is what we adopted, but then the Android story is not technically vertical. Any suggestion is appreciated!

Thanks,
Manu

[Carlos Garcia Navarro]

Hi Manuele,

Is the same team working on iOS and Android? Or do story 1 and story 2 belong to two different teams, projects,boards? I personally don't like to have to maintain two stories manually aligned. Could you have one story with three subtasks: subtask for iOS, subtask for Backend, subtask for Android? Thanks

[Manuele Piastra]

Hi, thanks for coming back to me. They work in the same team on iOS and Android. We used to have in the same story subtasks for iOS, Android and backend but then we started having different stories per platform, because the velocity between ios and Android was quite different and the iOS guys claimed they had to wait for Android to be finished for them to also be able to move the work to done and show the value produced. What are your thoughts?

[Carlos Garcia Navarro]

Hi, I would have only one story for backend, and let the team decide who and when to take it. Maybe you can use a component to indicate OS (iOS or Android)?

[Alexa Țugulea]

Hi, I'd want to ask: but why if have one subtask, named "Backend Mobile" with the checklist consisting of 2 points: IOS and Android. I have the same kind of issue and trying to find the best solution.

[Jonathan Arad]

Thanks everyone for weighing in, most helpful!

The key question from my perspective is the definition of a Story.

I believe it's a unit that delivers value to a user that fits in a Sprint.

Derived from this definition, the Story includes content to be done from various teams (FrentEnt, BackEnd, Dev.Ops, Algo, etc.).

The issues I have, if you agree with the definition above, the Subtask the only toll to create tasks per team member (for all teams involved):

1. who is the owner of the Story?
2. how can you assign and track the development of Subtasks in a Sprint?

Thanks,

J

[Artem Drobotenko]

> 1. who is the owner of the Story?
Product Owner / QA Lead / Project Manager / whoever observes the result

> 2. how can you assign and track the development of Subtasks in a Sprint?
subtasks can be assigned and have workflow status. they are nicely visualized on the Current Sprint Board