S’intéresser à la taille de ses user stories et les découper lorsqu’elles sont trop grandes est une bonne pratique. Cela permet d’éviter l’effet tunnel, de produire de la valeur rapidement et de contribuer à une meilleure organisation du travail de tout le monde. Encore faut-il les découper efficacement afin qu’elles soient testables et créent de la valeur.

Imaginez un sprint d’un mois dédié au développement d’une user story. Comment l’équipe va t-elle s’organiser pour la développer et la tester ? On pourra certes utiliser la granularité « tâche » pour découper le travail de développement, mais comment les testeurs vont-ils pouvoir s’occuper de tout ça? Testent-ils la user story dans son intégralité à la fin du sprint ? Peut -on tester des tâches de développement ? Si les développeurs découpent en tâches, peuvent-ils leur associer des tests d’acceptance ?

A l’inverse, remplir un sprint de cinq à sept user stories rendra possible le test de chacune d’elles dès lors que le développement sera bouclé. Plus besoin d’attendre la fin du sprint pour les considérer terminées. Comment disposer de plusieurs user stories alors que le client n’a exprimé qu’un seul besoin ? En le diffusant sur plusieurs user stories à l’aide des techniques suivantes.

Découpage vertical

C’est la meilleure approche pour découper une user story. L’article [Slices (Verticals), User Stories and Scrum] décrit bien ces « slices » (tranches) de user story, capables de traverser plusieurs couches d’architecture même si celles-ci font intervenir des compétences différentes (par exemple interface utilisateur, C# et SQL).

Le travail sur une « tranche » n’implique de développer que ce qui est nécessaire sur chacune des couches d’architecture concernées. Cela signifie que ces couches seront à même d’évoluer au fil du développement des prochaines tranches.

Pour s’entraîner, on pourra utiliser l’exercice de l’Éléphant Carpaccio d’Alistair Cockburn, qui est un très bon moyen de pratiquer et d’apprendre le découpage des user stories en tranches verticales très fines.

Décomposition à partir d’exemples

L’une des pratiques du BDD correspond à l’écriture d’exemples ou scénarios pour décrire le comportement attendu d’une fonctionnalité. Le besoin décrit dans une user story peut donner lieu à plusieurs scénarios. Si cette user story parait trop grande, il sera possible de la décomposer en associant par exemple une nouvelle user story aux scénarios identifiés.

Pour déterminer différents scénarios, on pourra s’inspirer de l’article de Jean Claude Grosjean qui liste 10 stratégies de décomposition des user stories en utilisant notamment les Personas, les opérations, les niveaux de qualité attendus, etc.

Découpage horizontal

C’est de loin le plus mauvais choix de découpage et malheureusement le plus fréquent. En avançant horizontalement, c’est-à-dire en isolant le développement de chaque couche d’architecture, il devient difficile d’associer une user story, issue d’un tel découpage, à de la valeur pour l’utilisateur. Imaginons un sprint dédié à la réalisation d’une interface utilisateur, quel bénéfice pourra tirer le client d’une interface complètement réalisée à laquelle aucune fonctionnalité n’est encore connectée. Certes, on pourra obtenir le feedback de l’utilisateur sur le design de l’interface, mais il n’est pas nécessaire de la développer intégralement, mieux vaut prévoir un prototype.

Il n’est pas évident de s’orienter vers le découpage vertical, car la tentation est forte de terminer un étage avant d’en commencer un autre. Par le passé, il m’est même arrivé d’augmenter le périmètre de user stories afin de répondre à d’autres besoins, pas encore priorisés. J’avais l’impression que cela permettrait de faire gagner du temps au projet, mais dans les faits, la user story nécessitait plus de temps à développer et à tester, mettant en péril le sprint. Il est d’ailleurs arrivé que les fonctionnalités annexes développées n’aient servi à rien, car jamais connectées à un besoin validé.

Et vous, quelle expérience retenez-vous du découpage horizontal ou vertical ?

photo credit: Lori Greig via photopin cc