Une Userstory indépendante
Dans cet article, nous allons vous parler d’un sujet “touchy” qui vous concerne sûrement :
L’indépendance d’une Userstory
Chacun a sa manière d’écrire et de découper ses Userstories, nous ne vous proposerons pas de modèle à suivre, car le modèle, c’est le vôtre. C’est la raison pour laquelle cet article vous proposera uniquement des indications et des aides.
Savez-vous d’où vient cette notion d’indépendance ?
Son origine vient de la méthode INVEST qui permet de définir une partie des critères de “Definition of Ready” (DoR) d’une Userstory.
En résumé, elle indique si votre Userstory est prête ou non à rentrer en développement.
Un petit rappel de la méthode INVEST
I — Independent. Une User Story indépendante des autres User Stories notamment pour faciliter son développement
N — Negociable. Négociée, discutée dès les réunions d’estimation et de planification de la version
V — Valuable. Source de valeur pour le Client final ou l‘utilisateur
E — Estimable. Estimée par les équipes de développement. Cette estimation doit être faite en fonction des autres Userstory déjà terminées.
S — Size Appropriately. Le plus souvent petite car susceptible d’être traitée (livrée et testée) par l‘équipe le plus rapidement. Elle pourra être redécoupée pour avoir une taille plus appropriée.
T — Testable. Testable avec des critères d’acceptation rédigés. Une Userstory non testable ou vérifiable, n’est pas une User Story.
Pourquoi une Userstory doit être indépendante ?
La dépendance entre des Userstories peut engendrer une triture des méninges et des maux de tête pour :
- Organiser l’envoi en développement des tickets au bon moment,
- Eviter les blocages de tickets qui attendraient des développements pour être finalisés,
- Eviter les reprises de développements ou de tests de tickets débloqués.
« Un travail réalisé en continu prend moins de temps et d’énergie que lorsqu’il est réalisé en plusieurs fois » — Loi de Carlson.
L’indépendance des Userstories permet des développements parallélisés, une plus grande sérénité pour l’équipe et le Métier et des objectifs tenus.
Dépendance : La Userstory n’est pas autonome pour délivrer de la valeur.
Adhérence : La Userstory est autonome sur son périmètre mais son travail peut impacter une autre Userstory
Mais, peut-elle être vraiment indépendante ?
En théorie, oui … mais en pratique, par forcément.
Il existerait 3 types d’indépendances :
Une indépendance fonctionnelle,
Une indépendance technique,
Une indépendance entre fonctionnalités.
Il est toujours compliqué d’écrire une Userstory indépendante. C’est la raison pour laquelle le moment du découpage est primordial. Cependant, il ne faut pas oublier que son découpage ne repose pas que sur le Product Owner ou le Business Analyst, il repose bien sur toute l’équipe.
N’hésitez pas à lancer un atelier d’Event Modeling qui vous aidera à bien découper vos fonctionnalités avec toute votre équipe. Cet atelier vous permettra aussi :
- De travailler sur le sujet avec toute l‘équipe en amont d’une Release/Sprint,
- D’avoir une vision fonctionnelle et technique suite aux échange entre les intervenants pour pouvoir bien découper et prioriser.
C’est aussi au moment des 3 Amigos que le Product Owner/le développeur/le testeur se mettent d’accord sur le découpage de la Userstory, sur l’écriture de ses règles et de ses exemples (via l’Example Mapping).
Un outil qui pourrait vous aider à écrire/découper vos Userstories : le Split Poker
Son indépendance fonctionnelle
Pour qu’une Userstory soit indépendante fonctionnellement, il faut que ses règles ne dépendent pas de règles décrites dans une autre Userstory.
Au moment de l’écriture d’une Userstory, posez-vous la question :
“Et si mon projet devait s’arrêter maintenant et que ma Userstory était la dernière à être développée, ajouterait-elle de la valeur à elle-seule ?
Si la réponse est “Non”, alors, songez à la réécrire pour que votre réponse devienne “Oui”. Ce n’est pas forcément facile à faire, mais cela permet de voir le besoin sous un autre angle.
Exemple : “Je renseigne et valide mes informations personnelles”.
On voit bien que cette Userstory apporte une valeur fonctionnelle et qu’elle peut être testable. Un découpage plus fin aurait pu être:
- “Je renseigne mes informations personnelles”,
- “Je valide mes informations personnelles”
Mais, dans ce cas, la vraie valeur ajoutée est dans le 2ème étape et non dans la première, car c’est à ce moment que les informations seront prises en compte. Si le projet devait s’arrêter, la première Userstory n’apporterait pas de valeur car elle dépend de la seconde.
Nous pourrions prévoir plutôt ceci :
- “Je renseigne le nom et prénom et je valide ces informations”,
- “Je renseigne mon adresse et code postal et je valide ces informations”
- Etc.
Chacune apporterait alors une valeur ajoutée indépendamment des autres.
Son indépendance entre fonctionnalités
La Userstory est-elle totalement indépendante fonctionnellement ?
Pas forcément, car il faut aussi penser les Userstory au niveau des fonctionnalités (Minimum Marketable Feature ou MMF). On développe une brique (une Userstory) mais l’ensemble cohérent, la réelle valeur ajoutée, ne se fait qu’au sein d’une fonctionnalité. Cependant, ce n’est pas un problème si les Userstories sont bien indépendantes et peuvent être développées/testées seules.
Dans notre exemple plus haut :
Soit la fonctionnalité de se connecter au site existe déjà, Soit cette fonctionnalité est en train d’être développée dans la même fonctionnalité. On constate que cette Userstory dépend finalement de la connexion. Sa valeur ajoutée ne sera donc pas apportée tant que l’utilisateur ne pourra pas se connecter.
Il faudra attendre que la fonctionnalité soit traitée pour apporter de la valeur.
D’autre part, en fonction des priorités métier, nous avons aussi des dépendances entre fonctionnalités. Imaginons que le Métier souhaite que la fonctionnalité d’envoi de notification soit lancée après la fonctionnalité sur les informations personnelles. Il faudra bien que l’on attendre la feature “informations personnelles” avant de lancer celle sur la notification.
Son indépendance technique
Techniquement, pour qu’une Userstory soit indépendante, il faudrait penser que l’on pourrait la développer à tout moment, sans nécessité d’avoir un ordre entre les Userstories de la fonctionnalité, même si fonctionnellement cela n’avait pas de sens.
Une cartographie des impacts techniques
Pour bien préparer votre découpage, il est important de connaitre les impacts techniques, d’où l’importance de l’Event Modeling pour les définir. Pas de dépendance entre Systèmes Applicatifs ? Parfait. Une dépendance constatée ? L’équipe va effectuer un découpage pour avoir le moins d’impact possible.
Un découpage purement technique ?
Il vaut mieux éviter un découpage en séparant cartes techniques et Userstories car, souvenez-vous de cette question posée précédemment :
“Et si mon projet devait s’arrêter maintenant et que ma Userstory était la dernière à être développée, ajouterait-elle de la valeur à elle-seule ?
En préparant techniquement l’arrivée d’une Userstory :
- Vous ne commencerez à délivrer de la valeur qu’une fois vos tickets techniques développés (au risque d’avoir des itérations 100% “techniques”),
- Vous risquez de revenir sur vos développements techniques car le besoin aura peut-être changé entre-temps,
- Vous aurez des difficultés pour tester votre “coquille vide” technique (que d’interventions manuelles pour modifier une base de donnée et lancer un Soapui pour tester un service qui ne répond pas encore car il n’a pas encore de règles …),
- Vous n’aurez de feedback de vos évolutions qu’une fois les Userstories développées.
Il est très difficile d’avoir des Userstories totalement indépendantes les unes des autres, mais en démarrant par une Usertory simplifiée incluant des services techniques “de base”, mais qui s’enrichiront peu à peu, cela permettra de :
- Apporter un premier feedback fonctionnel et technique au plus tôt,
- Réduire les dépendances et le temps d’attente pour développer les prochaines Userstories,
- Simplifier vos tests.
Exemple : “Récupération des infos personnelles d’un client”.
Ce besoin implique :
- Un service de contrôle de données renseignées par l’utilisateur,
- Un service de recherche client,
- Un service de récupération de données.
Nous pourrions découper le besoin de la façon suivante :
- Une Userstory de base avec la connexion au service de contrôle de données + le service de recherche client. Ce qui permettrait d’apporter de la valeur au plus tôt (le fait de “Reconnaitre que l’utilisateur est bien un client”).
- Une Userstory dans laquelle nous pourrions faire appel au service de récupération de données qui semble plus complexe pour répondre totalement au besoin.
