Comment découper ses user-story ?

Ecrit par << Paquet Judicaël >>

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 ?

Cette article va proposer différentes façons pour découper en tranches fines le backlog produit afin de proposer des user-story gérables par les équipes de développement au sein d’un sprint.

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.

Découpage vertical

Moins utilisée mais probablement la plus logique en soit, cette pratique consiste à découper les user-story 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. »

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 plus fréquent mais qui dans le fond 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 n’est pas à privilégier. 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.

5 réponses sur “Comment découper ses user-story ?”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.