Le découpage des User stories fait partie des activités structurantes d’un Product Owner. Une US doit être suffisamment découpée pour être réaliser dans un seul sprint. Je dirai même que le poids d’une US doit représenter 1/10 à 1/6 de la vélocité de l’équipe.
Pourquoi et comment découper une User Story ?
Pourquoi découper une User Story ?
Avoir des US découpées a plusieurs bénéfices :
- Motivation de l’équipe : il est plus motivant de passer 3 US à DONE plutôt qu’une
- Correction des régressions : l’impact d’une US bien découpée est plus maîtrisé qu’une grosse US, donc, en cas de régression il est plus simple de mettre en place la correction.
- Feedback rapide : grâce à la livraison rapide de la valeur au client on peut réduire l’incertitude et le risque de perdre du temps à développer une US qui ne couvre pas le besoin
- Les critères d’acceptation sont plus faciles à identifier : à travers les échanges entre le PO, l’équipe et les acteurs projet.
Comment découper une User Story ?
Je découpe mes US en collaborant avec l’équipe projet et en se posant les questions suivantes :
- Est ce qu’on a un découpage vertical qui permet de livrer de la valeur ?
- Est ce que l’US représente bien une seule opération ?
- Est ce qu’on a des règles de gestion à dé prioriser ?
- Est ce qu’on peut regrouper les critères d’acceptation pour créer de nouvelles US ?
- Est ce qu’on a besoin d’une US technique / Spike ?
1- Découper Verticalement / horizontalement
Un découpage vertical se base sur la valeur métier, on va se focaliser sur un résultat démontrable indépendamment de la partie technique. Une US découpée verticalement peut demander des développements Front, Back, Base de données…
Un découpage horizontal est un découpage technique où on va chercher à avoir une US par composant architectural : US pour le Front, US pour le Back, US pour la base de données…
Une US raconte l’histoire d’un utilisateur, elle exprime un besoin métier qu’on perd avec cette granularité de découpage. Ce découpage vertical est intéressant mais il doit être réalisé par les développeurs lors du découpage d’une US en tâche.
2- Identifier les opérations
Il faut bien identifier les opérations d’une US pour s’assurer qu’il n’y a pas de complexité cachée. Exemple d’US d’un site e-commerce :
“En tant qu’utilisateur je souhaite acheter des articles”
Cette US à l’air très simple et évidentes pour une site e-commerce mais les besoins non exprimés sont :
- “En tant qu’utilisateur, je souhaite consulter les articles”
- “En tant qu’utilisateur, je souhaite ajouter les articles à mon panier”
- “En tant qu’utilisateur, je souhaite consulter mon panier”
- “En tant qu’utilisateur, je souhaite supprimer des articles de mon panier”
- …
L’identification des opérations permet de découper les US plus finement tout en apportant de la valeur à l’utilisateur. En faisant un story Mapping ce découpage se fera de façon naturel.
3- Simplifier ou dé-prioriser des règles de gestion
Si notre US est coûteuse, il faut se demander si nous avons des règles de gestion à simplifier ou à reporter à un autre sprint.
Exemple d’une fonctionnalité :
La consultation des articles soldés est proposée uniquement aux utilisateurs abonnés de plus d’un an et qui ont fait des achats d’un montant supérieur à 1000 euro
On peut découper cette fonctionnalité en deux partie :
- Consulter des articles soldés
- Restreindre la consultation aux utilisateurs autorisés.
La première partie apporte de la valeur et la deuxième la complète.
4- Découper une User Story en regroupant les critères d’acceptation
Chaque US à des critères d’acceptation généralement exprimés en BDD. On peut regrouper les critères d’acceptation et chaque sous ensemble cohérente apportant de la valeur donnera lieu à une nouvelle User Story.
5- Identifier des US techniques/spike
Lors de l’affinage ou Grooming d’une US ou lors de son pesage, les développeurs peuvent identifier une complexité technique. Dans ce cas, on peut découper l’US fonctionnelle en deux US :
- Une US technique/ Spike qui permet de mettre en place la partie technique
- Une US fonctionnelle pour l’implémentation de la partie métier
La priorisation entre les deux US dépendra du contexte du projet. J’ai une préférence pour l’implémentation de la partie technique en premier pour dé-risquer le développement de la partie fonctionnelle. Mais vu que les plannings sont souvent serrés, on peut mettre en place la partie fonctionnelle pour démontrer la valeur et développer par la suite la partie technique. Cependant, il faut faire attention au coût du re-work et au % de dette technique accepté dans le projet.
6- S’adapter à l’équipe projet
L’objectif d’un PO est de maximiser la valeur d’un produit, pour cela, il faut profiter de l’intelligence collective. Le découpage des US doit se baser sur les échanges avec l’équipe de développement, les testeurs tout en prenant en compte leurs contraintes.
Source : Slices (Verticals), User Stories and Scrum
