Bonjour
Je souhaite comprendre comment vous rédigez les user stories backend. Par exemple, pour une API de modification de profil, dois-je reproduire la même user story côté frontend, ou existe-t-il un format spécifique à suivre ?
Hum… ça dépend. Quel est le but de ce que tu essaies de rédiger ?
1 « J'aime »
Est ce que tu as moyen de rédiger ton US de sorte qu’elle décrive un scénario de bout en bout (back end et frond end) ?
Quel est l’incrément minimum qui apporte de la valeur à ton client (celui à qui vous allez faire une démo) ?
Et éventuellement, ensuite, faire la distinction back/front seulement dans le découpage technique
1 « J'aime »
Une user story, par définition, est orientée utilisateur.
La notion frokt et back ne devrait pas être présente.
C’est souvent un decoupage malheureux par stack technique, il vaut mieux couper verticalement
1 « J'aime »
Tu as un exemple à soumettre?
USER story => expression normalisée d’un élément de backlog dont la formulation vise à mettre un focus sur 3 points majeurs pour une approche orientée sur L’UTILISATEUR de ce qu’on envisage de livrer (et dans un espoir fondé d’obtenir de sa part un feedback afin d’orienter les choix suivants)
Donc. qui est utilisateur de l’API ?
A priori , un développeur qui configure son client ?
1 « J'aime »
pour mettre les tickets sur jira / pour le découpage interne au sein de l’entreprise
Bonjour Mary Bgh,
Je vais tenté de faire court 
et simple, on va dire qu’il faut que je progresse dans ce sens.
Pour moi, Il y a 2 type de US que l’on peut rédiger. (Si d’autres SM&Coach qui sont dans le coin pense que je dis une connerie ne pas hésitez à me le montrer.)
Donc je disais 2 type d’US : Nous avons les plus classique que beaucoup de PO essaye, tant bien que mal de mettre en place : US feature team
Et sinon le plus souvent nous avons US component team.
en lisant ton message j’ai plus l’impression que tu es dans l’US Component Est-ce que c’est bien le cas ?
La diff entre les deux :
US feature : Comme sont nom l’indique nous serons une une feature avec ce que cela implique
En tant que
je veux / afin de
ici tout le monde le rajoute pas => Je souhaites <ce que ça va apporter>
Pour que <Ici ce sont nos critères d’acceptances.>
Pour la US component : Pour moi
Je souhaite <ce que ça va apporter>
Pour que <critère d’acceptances>
Est ce que ça te parle un peu ce que j’ai écrit ?
En attendant ta réponse je te souhaites bon courage dans la rédaction des tes US 
, je sais que c’est pas un travail facile.
1 « J'aime »
Bonjour, je t’invite à tester les sous-taches de Jira pour permettre aux développeurs de visualiser de manière indépendante l’avancement de leur travaux dans le board kanban.
Cela permet au PO et à l’équipe de bien identifier en quoi chaque développement répond à de la valeur pour l’utilisateur.
Cela facilite aussi parfois la validation du ticket.
J’abonde largement cette option de jira. Je présente cela comme ceci : le récit (us) décrit le « quoi » et les sous-taches décrivent le « comment ». Parfois le comment est superflu car l’équipe maîtrise le sujet mais parfois, l’équipe formalise le comment si elle le juge nécessaire. Cela permet d’avoir un backlog propre et majoritairement fonctionnel.
Il faut cependant bien configurer les tableaux et mettre en place des filtres rapides pour plus de lisibilité.
J’ai souvent rencontré des équipes que disaient « j’aime pas les sous tâches » uniquement parce qu’elles ne savaient pas configurer les tableaux convenablement.
Si vous dite ce qu’il faut faire, c’est pas une User Story.
Une User Story c’est une hypothèse que le PO veut tester.
On imagine qu’en tant qu’un certain type d’utilisateur (un client , un qui profite de la valeur ajoutée du produit) on a un besoin (afin que) et une (nouvelle) expérience utilisateur qui y répond, un goal (je veux que)
Si on n’est pas sur une USER story, pas besoin de rédiger en As a user …
Si vous dite ce qu’il faut faire, C’est une tâche.
Une user story ne raconte même pas ce qu’on veut obtenir.
Elle raconte la situation qu’on imagine pendant la discussion (#Card-Conversation-Confirmation) que l’équipe va avoir pour « écrire ensemble » ce qu’on va faire (découpe en tâches)
2 « J'aime »
Est-ce que tu peux nous donner des tips pour configurer le tableau convenablement ?
JIRA Cloud ou Jira Datacenter ?
Ok. Et ils/elles en pensent quoi les dev dans ton équipe de ce sujet ?
2 « J'aime »
Je connais que datacenter pour l’instant.
Est-ce-qu’il ya une grande différence entre les 2?
En fait je fais toujours en sorte de respecter la hiérarchie suivante : épopée->récits->tâches
A chaque projet jira, je livre un board Scrum et un board Kanban ; je donne la main à tous les équipiers.
Voici la conf du kanban :
General : je supprime le filtre « kanban board sub-filter » pour le remettre plus tard quand la gestion des versions sera maîtrisée par l’équipe.
Columns : je glisse l’état backlog dans la partie backlog ; je supprime la colonne backlog ; j’active la vue des épopées (uniquement dispo dans le cloud, pas dispo en DC)
Swimlanes : basées sur épopées
Quick Filters : tu fais le mieux pour les équipiers pour que ce soit le plus convivial possible
Card colors : basé sur issueTypes
Card layout : comme tu vex
Working days : util pour les jours ouvrés
Timeline : activé (pas dans DC)
===> tu verras dans le backlog de la vue kanban les taches sous les récits.
ATTENTION : bien penser à replier toutes les tâches avant de glisser le récit dans le « selected for dev » en faisant cela, le récit et toutes les taches seront déplacés.
-------
Voici la conf du Scrum :
General : rien de particulier
Columns : « Select for Dev » et « Backlog » sont dans la colonne « ToDo »
Swimlanes : basées sur épopées
Quick Filters : tu fais le mieux pour les équipiers pour que ce soit le plus convivial possible
Card colors : basé sur issueTypes
Card layout : Backlog : Bien que pas nécessaire ici, j’ajoute parfois le champs SubTasks (pas dans DC)
Estimation : Story Points ou issue count (si noEstimate) ; pas de time tracking sauf sous la torture
Working days : util pour les jours ouvrés
Timeline : activé (pas dans DC)
--------
Dans les 2 boards, on verra le récit et les taches. Il suffira de déplacer les taches dans la bonne colonne pour voir où on en est. quand TOUTES les taches seront terminées il proposera de terminer le récit. Il est possible de faire de l’automation pour mettre à jour le récit en fonction de l’état des tâches mais franchement, c’est pour se faire plaise !
Pourquoi on voit les taches dans le backlog kanban et pas dans le backlog Scrum me direz-vous ? Cela rejoint ta question : le backlog en mode Scrum ne devrait contenir que du « fonctionnel » et rarement des taches techniques, du « Quoi », le comment se discutera en équipe lors du sprint planning (ou un peu avant lors de raffinage) donc, ce qui est important lors de ce sprint planning c’est d’afficher les infos dans la partie droite : issueLayout (cloud) ou détail dans la conf du board (DC).
Sans faire de screenshot, c’est pas facile de bien expliquer mais fais-toi un projet jira bac à sable … (si c’est as déjà fait …)
Merci je vais regarder
Moi, j’aime pas les sous tâches, et ce n’est pas un problème JIRA, pas un problème d’outil.
Les sous taches repondent à une problématique si cette dernière est avérée. Si la problématique n’existe pas, pas de raison de faire de la surgestion.
Quand l’équipe tire une carte, ce n’est pas un dev, il y a potentiellement plusieurs devs. Tout le monde n’est pas full stack.
Quand un dev full stack tire cette même US, il ne va pas créer de taches, il fait chaque critère d’acceptance, et l’implemente dans la techno que ça implique. Et quand tous les critères sont OK, verts, il a terminé et presente l’US.
Quand un dev front tire une carte, et qu’il y a du back, donc de l’api. Il va devoir donner à manger à un autre dev pour tout ou partie des critères d’acceptations. Et ça, ce n’est pas la problématique du PO, du métier.
Comme d’autres l’ont écrit, le « Comment » ne figure et ne doit surtout pas figurer dans une US.
C’est plus clair?
Avec un exemple, je peux te le démontrer facilement
1 « J'aime »
Dans mes équipes, on analyse rapidement les stack technos impactées dans une US, on le fait lors du refinement.
Techniquement, on agoute une étiquette front, back, etc.
On aurait aussi pu le faire avec le composant, c’est pareil.
Du coup, quand on tire une carte, on voit qu’il faut plusieurs competences, du coup, il y a ces competences lors du 3 Amigos
Quand les devs ont terminés, la carte est montrée.
Ça n’empeche pas de la découper si elle est trop grosse. Mais surtout pas en stack techno / component, on decoupe fonctionnelllement.
Je ne vais pas vous refaire les excellentes videos scrum life sur l’Example Mapping et le decoupage des cartes.
La sous-tache est l’élément de gestion de projet si on considère chaque sbi(sprint backlog item) comme un micro projet.
Une sous-tache s’assigne a une personne, alors qu’un sbi reste assigné a toute l’équipe de développement.
On crée une sous-tache pour décrire ou documemter ou rassembler les assets d’une une activité liée à la réalisation d’un sbi.
On n’est pas obligé de créer des sous tâches pour tout. Juste pour celles ou on doit partager, ou ne pas oublier.