Sur nos UserStory Jira, on a un champs « Autres Intervenants » qui permet de mettre toutes les personnes qui doivent intervenir sur la carte. Dans le cas d’une carte front et back, l’un des deux s’affecte l’US et l’autre se mets sur le champs autres Intervenants.
Vous l’avez compris, les sous taches, c’est vraiment le dernier recours.
Par contre, est ce que ça répond à la problématique ?
Ah… C’est bien de se poser cette question. Peut être un peu tard, mais bien… 
c’était pas ne pas dire que j’ai l’impression qu’on ne répond pas au bon problème
je ne peux que vous conseiller l’excellent article d’un de mes collègues : Comment j’écris un webservice ou une API dans ma Usertory ? | by Silvere Duval | Just-Tech-IT | Medium
Je pense que cela peut répondre au pb exposé car les API sont un des moyens (le comment) de répondre à un besoin (le quoi). Dans une équipe pluridisciplinaire, il faut bien que l’équipe s’y retrouve dans ce cas, nous avons bien l’us « En tant que personae je souhaite modifier mon profil dans le but de mettre à jour mon compte » avec les critères d’acceptation qui vont bien en Gherkin (j’imagine là …) je pense que la fine équipe sait qu’il faudra peut-être une doc utilisateur à mettre à jour pour cette US, de faire le front qui va bien, de préparer son automatisation avec Cypress, de faire l’API et son Postman qui va bien, de mettre à jour le plan de test pour la non regression dans l’outillage qui va bien (en gros tout ce qui est dans la DoD de l’équipe).
Enfin, si tout n’est pas dans une seule US, il est bien possible de dupliquer l’US avec un composant par type d’usage … cela dépend vraiment des organisations mais tout est possible et les équipes s’organisent au mieux pour atteindre l’objectif du sprint, je persuade souvent les équipes à essayer du 3A suivi d’un raffinage avant le SprintPlanning dans le but garantir la bonne compréhension du besoin par l’équipe (s’il y a des soucis de compréhension relevés lors des rétro bien sûr, je n’impose jamais …)
La distinction component team / feature ne devrait pas avoir d’incidence sur le formalisme de l’US.
Component / Feature va plus correspondre à une structuration de ton appli / orga
L’US, elle doit raconter une histoire du point du bénéficiaire sous la forme d’une hypothèse, donc répondre à :
Pour QUI ?
Pour quelle intension du bénéficiaire ?
Pour quel contexte du bénéficiaire ?
Pour quel bénéfice du bénéficiaire ?
Si c’est une action technique, je préfère les distinguer en les nomant « Tâche technique » pour peu que cette tâche soit plut assimilé à de la maintenance (problème connu, solution connue - du point de vue Cynefin , une tâche SIMPLE).
Si une tâche technique contient une hypothèse d’amélioration, se poser la question de son status d’US en se reposant les questions du point de vue US