Quand les coachs agiles arrivent dans une nouvelle mission où le but est de transformer les équipes en place en Agile voire en Scrum, il y a souvent un premier sujet essentiel à traiter : comment découper ses user-story ?
Cet article va proposer différentes façons pour découper en tranches fines le backlog produit afin de proposer des user-stories facilement réalisables par les équipes de développement au sein d’un sprint.
D’ailleurs, vous pouvez regarder la vidéo de la minute agile qui parle aussi de ce sujet :
Mais pourquoi découper nos user-story ?
Il existe plusieurs raisons qui permettent de justifier le découpage des user-story :
- Une user-story doit être réalisable intégralement dans un Sprint
- Avoir une meilleure transparence sur le projet
- Avoir un meilleur feedback et plus régulier
- Avoir un meilleur apprentissage
- Avoir une livraison de valeur plus rapide
En effet, le découpage de user-story apporte vraiment beaucoup à l’organisation Agile mise en place.
Cependant, le découpage n’est pas si simple et il existe différentes méthodes pour le faire.
Commencer avec le concept de MMF
J’aime beaucoup l’utilisation du concept de MMF (Minimum Marketable Feature) pour commencer mon découpage. Quand nous avons une fonctionnalité, qu’est-ce qui sera essentiel et qu’est-ce qui sera optionnel ?
En savoir plus sur le MMF : Travaillons nos fonctionnalités avec le MMF
Par exemple, prenons un formulaire de contact comme présenté ci-dessous :
Nous avons une user-story principale :
“En tant que client, je souhaite contacter le service client pour obtenir de l’aide”
Cette user-story est obligatoire pour le site; le service client est essentiel pour tous les clients. Donc nous considérons que cette user-story est MMF.
Mais, nous pouvons avoir un meilleur rendu de la fonctionnalité si nous ajoutons quelque chose; par exemple, cette user-story :
“En tant que client, je veux que la ville soit en auto-completion quand je saisi mon code postal”
Cette user-story est user-friendly mais n’est pas nécessaire to avoir ce formulaire fonctionnel. Donc, nous considérons que cette user-story n’est pas MMF.
Ces deux user-stories peuvent être livrées séparément parce que nous avons une user-story MMF et une autre. La première sera livrée lors de la première version du projet (ou première partie du développement) et la seconde plus tard.
Donc, ces deux user-stories seront indépendantes lorsque nous les livrerons.
Découpage vertical
Voici le type de découpage que je peux fortement vous conseiller. Cette pratique consiste à découper les user-stories sans se soucier des aspects architectures. Les user-story pourront potentiellement intervenir sur différentes couches d’architecture qui ne sont pas gérées par les mêmes compétences (C#, PHP, React/Node…).
Cette démarche se complexifie quand on a une user-story qui va concerner deux équipes différentes d’où le découpage horizontal utilisé par de nombreuses équipes.
« En tant que client, je souhaite pouvoir payer mon panier avec Paypal. »
Les user-stories sont indépendantes
Chaque user-story doit être indépendante. Par exemple, nous allons créer une user-story par moyen de paiement:
“En tant que client, je souhaite pouvoir payer mon panier avec ma carte de crédit.”
“En tant que client, je souhaite pouvoir payer en 3 fois.“
Et quand une user-story a besoin de quelques équipes?
Cette user-story qui est le fruit d’un découpage vertical peut impliquer plusieurs équipes dans l’entreprise : l’équipe front qui va intégrer le moyen de paiement sur le site, l’équipe paiement qui va gérer ce nouveau moyen de paiement dans leur PSP et l’équipe back qui devra reconnaître ce paiement. Il n’est pas rare que le front, le PSP et le back soient tous sur des systèmes très différents.
Ce type de cas arrive et il y a des choix à faire comme affiner le découpage mais en cassant le test qui concernait l’ensemble de la fonctionnalité.
Voici un exemple de découpage :
« En tant que client, je souhaite voir le moyen de paiement Paypal affiché. » (pour le front)
« En tant que client, je souhaite pouvoir payer mon panier avec Paypal. » (pour le PSP)
« En tant que responsable des commandes, je souhaite voir les commandes payées avec Paypal. » (pour le Back)
Nous venons d’effectuer un découpage horizontal mais qui semble rendre chaque fonctionnalité indépendante (bien que dans le fond si c’est vrai, l’intérêt final est d’avoir les 3 pour pouvoir réellement mettre ce moyen de paiement en production).
Mais alors qu’elle est la bonne pratique dans ces cas particuliers ?
Pour être honnête, c’est très difficile à déterminer quand on a pas le contexte final.
Il peut y avoir deux pratiques différentes. Certains se prononceront avec conviction sur l’une des deux à utiliser ; pour ma part, je pense que le contexte sera la réponse à la question.
Découpage vertical puis duplication
Quand vous avez des concepts comme le Scrum of Scrum (Scrum of Scrum : Coordonner plusieurs équipes) avec des comités PO, il peut-être intéressant de dupliquer la user-story pour chaque équipe et de ne pas la découper à nouveau.
Le CPO validera la fonctionnalité quand les 3 équipes auront terminées leur user-story sachant qu’il aura fait le nécessaire pour que les 3 équipes traitent cette user-story pendant la même période.
Découpage vertical puis horizontal
Quand l’organisation des équipes n’est pas du tout optimale pour ne pas dire nulle dans certains cas, il est préférable de faire un deuxième découpage horizontal qui amène à la création des 3 user-story.
Il sera par contre indispensable que les équipes communiquent pour la livraison de la fonctionnalité dans son intégralité bien que l’équipe back et l’équipe PSP pourraient livrer leur user-story avant l’équipe front.
Comment découper verticalement ?
Ce découpage peut se faire en suivant un workflow utilisateur comme les exemples suivants :
« En tant que client, je souhaite pouvoir afficher le contenu de mon panier »
« En tant que client, je souhaite pouvoir me connecter à mon compte après la confirmation de mon panier »
« En tant que client, je souhaite choisir le mode de livraison pour mon panier »
C’est assez classique comme méthode mais elle fait parfaitement le travail.
Découpage horizontal
Le découpage horizontal est un découpage que nous voyons encore présent au sein de certaines structures. Mais celui-ci pose un réel problème : la perte de la notion d’une fonctionnalité livrable à la fin de la user-story.
Dans l’idée, ce type de découpage rend vos user-story souvent dépendantes à d’autres user-story.
Voici le type de découpage horizontal que nous pouvons rencontrer :
- par scénario : celui qui fonctionne, celui qui ne fonctionne pas voire des scénario alternatifs
- par opération : par exemple sur des apis ou des interface back-office de découper par type d’opération : CRUD (create, Retrieve, Update, Delete). Ce déoupage peut-être vu comme vertical dans certains cas où il y a une réelle indépendance entre les user-story.
- par type de données : par exemple pour séparer l’option en français et en anglais
- par personna : découpage pour définir différents utilisateurs : client, visiteur…
Ce type de découpage complexifie la mise en production des fonctionnalités donc est fortement déconseillé. Cependant vous pourrez la rencontrer régulièrement dans des projets agile car elle est encore la plus répandue.
Faire des user-story INVEST
L’acronyme INVEST est intéressant car il définie les critères d’une user-story de qualité.
- I pour Indépendante : chaque user-story doit être indépendante des autres
- N pour négociable : les détails doivent être négociables. C’est pour cela qu’on écrit une user-story en une seule petite phrase afin de ne pas forcer les détails
- V pour valeur : chaque user story doit apporter de la valeur business pour les métiers ou les clients
- E pour Estimable : chaque user-story doit être estimable par les équipes de développement ; pour cela, ces équipes doivent bien les comprendre.
- S pour Suffisamment petite : chaque user story doit être bien découpée afin d’être livrée au sein d’un seul Sprint.
- T pour Testable : il faut que toutes les user story soient testables.
En respectant ces règles, vos user story seront de meilleures qualités et permettront de mieux organiser vos sprint.
Conclusion
Le découpage de user-story est souvent complexe mais il est important de le faire dans les meilleures conditions possibles car le résultat de ce découpage sera important pour le bon déroulement des sprint des équipes.
N’hésitez pas à vous faire accompagner par des coachs Agile pour mener à mieux cette phase souvent très importante lors du démarrage de vos sprints. Les bons choix vous feront gagner du temps sur la suite de vos projets.
6 Rétroliens / Pings