Bonjour à tous les ScrumlifR,
avec mon équipe l’on développe actuellement une application mobile qui a une fonction qui doit afficher les infos de l’utilisateur (ici une cagnotte d’un programme de fidélité en points).
Cette application a besoin de se connecter à un backend que l’on développe en partie.
Pour l’us utilisateur l’on a : En tant qu’utilisateur je souhaite voir le solde de ma cagnotte afin de savoir ce qu’il me reste de points
Pour l’application l’on pense à : En tant qu’application je souhaite accéder à l’API cagnotte afin que je puisse l’afficher le solde de points à l’utilisateur
Et pour le backend à : En tant que backend je souhaite mettre à dispo une API cagnotte afin que l’application puisse me solliciter pour connaître le solde de points d’un utilisateur
De ce que j’ai lu cela n’est pas une bonne pratique de rédiger comme cela mais au niveau de l’équipe, et comme il y a des dépendances entre les us, l’on sait qui doit faire quoi et les us peuvent être livrées / testées indépendamment les une des autres.
Je suis grandement intéressé par vos retours en vous remerciant par avance.
L’US fonctionnelle suffit largement pour le PO, les deux autres ne sont pas réellement des dépendances mes activités techniques(tâches) pour les développeurs(surtout si les API et le backend sont gérés par la même équipe donc une feature team avec toutes les compétences nécessaires pour traiter de bout en bout les besoins fonctionnels) pour livrer cette fonctionnalité(« voir le solde de ma cagnotte »).
Si ce sont différentes équipes qui gèrent les différentes parties(component team), alors s’assurer de bien affiner et prioriser ces US soit pour être traiter dans le même sprint ou s’assurer d’abord que les dépendances techniques sont levées dans les premiers avant d’embarquer la fonctionnalité elle-même sur un autre sprint.
Un bon PBI(ex d’une bonne US) devrait être INVEST: Indépendante, Négociable, a de la Valeur(notamment métier), Estimable, assez petite(Small) pour être livré dans un seul Sprint et, Testtable(d’où la DoD et les critères d’acceptance)
Tout à fait en phase, ce qui compte est la persona
Une application et un backend, ne sont pas des personas.
Concernant la consultation de solde, il n’y a pas d’autre finalité que de consulter ses points?
J’aime bien donner un vrai but au « afin de » plutot que de reformuler juste le « Je veux »
Pour faire emerger cela, je demanderais ce que permettrait le solde, que peut faire le client avec un solde, acheter des produits, les convertir en autre chose, d’autres avantages?
Ce que tu nous presentes est pourtant ce que je retrouve soivent ici et là. Pour moi, c’est un flagrant deli de Component Team, ce qui est un antipattern à la pluridisciplinarité recherchée.
Certains vont qualifier, à tort, tes deux US app et back en Technical Story… en quoi le besoin est il technique. C’est issu d’un besoin utilisateur, en rien cela ne provient d’un besoin emergeant de l’équipe technique qui pourrait avoir envie de défendre une carte pour ameliorer la dette technique
Dans ton cas, je disais que t’as une US, et 2 voir 3 taches si ton sujet est d’affecter les « choses à faire » aux devs respectifs
Ce type de découpage BE-FE est aussi l’excuse parfaite que certains tems utilisent pour ne pas se parler et se rejeter la balle. je soutiens l’idée que c’est une US avec des taches partagées et les membres de l’équipe doivent se parler en tout temps pour travailler ces taches, les valider et arriver « ensemble » à livrer la fonctionnalité attendu. Rappelez-vous que l’utilisateur final s’enfiche de la notion BE-FE ce qui compte pour lui est que la fonctionnalité répond à son besoin!
P.S: c’est drôle! c’est exactement ce que je me tue à répéter à ma nouvelle équipe dans mon nouveau mandat lol
Il y a un dev caché derrière le PO
Le User Story n’a rien à voir avec le front ou back-end. L’US devrait être INVEST comme @Scrummer_Senschool a mentionné, après, il y a des bonnes pratiques comme le backlog refinement qui aide à décomposer les tâches complexes en parties gérables qui peuvent être abordées par la suite (avant le sprint planning meeting).
Un grand merci à tous pour vos réponses, je ne m’attendais pas à des retours aussi vite !
Me sachant allant dans la mauvaise direction, j’ai préféré demander mon chemin à la communauté et j’ai bien fait.
