Bien découper les User Story

Decouper StoryDernièrement j’ai été confronté à un découpage « technique » d’une User Story et malheureusement c’est quelque chose que je vois assez régulièrement.

Le problème initial est que l’équipe estime une User Story trop grosse pour pouvoir être terminée durant l’itération, il faut donc la découper sous peine de voir l’itération échouer (en effet, il est important de finir pour beaucoup de bonnes raisons qui pourraient être l’objet d’un autre post si cela vous intéresse). Bien sur il est préférable de garer une cohérence fonctionnelle à une User Story, c’est à dire utilisable pour créer de la valeur pour l’utilisateur, mais parfois elle est vraiment trop grosse.

Lorsque le Product Owner a du mal à trouver comment découper cette User Story, alors les équipiers proposent leur aide, ce qui est une très bonne chose, et malheureusement dans certains cas, le résultat est un découpage technique 🙁

Découpage Technique, qu’est ce que c’est ?

Cela consiste à découper la Story suivant les choix d’architecture du logiciel.

Par exemple, une première Story contenant la modification de la base de données, une deuxième décrivant la logique applicative et une troisième qui consiste à modifier l’IHM.

Pour savoir si une User Story est issue d’un découpage technique, demandez simplement aux équipiers « comment » ils prévoient de montrer la Story lors de la revue de fin de sprint. S’il doivent faire une opération que l’utilisateur ne sait pas faire (par exemple une requête en base de données), alors vous êtes surement en présence d’un découpage technique.

Souvent les raisons invoquées par les équipiers sont tout à fait valables, comme le fait d’avoir une charge de travail importante pour modifier la base de données, et qu’il n’est pas possible d’inclure des éléments fonctionnels compte tenu de la durée du sprint par rapport à cette charge de travail. Alors que faire ?

Comment faire autrement ?

Il n’y a bien entendu pas de technique unique qui marche à tous les coups et pourtant en insistant sur le fait d’avoir quelque chose qui soit montrable en revue de sprint et qui intègre la partie technique la plus complexe, l’équipe devient créative et trouve des solutions alternatives, en voici 2 exemples.

Exemple 1

La User Story consiste à créer des fichiers, avec des noms configurables, en agrégeant dynamiquement un grand nombre de données sous un format spécifique et différent en fonction des fichiers.

Proposition technique : Faire une story pour préparer la base de données, puis une story pour écrire un composant configurable qui agrège les données, et enfin une interface pour décider du nom du fichier et lancer la génération des données en fonction du type de fichier sélectionné.

Alternative : Faire une story qui, via un bouton unique dans l’IHM, génère 1 seul des types de fichier avec un nom fixe prédéfini (toto.txt si vous voulez) et « coder en dur » l’agrégation des données (pas de composant configurable), ce qui permettra aux équipiers de se consacrer sur la préparation des données en base tout en gardant quelque chose de montrable en revue.

Exemple 2

Pouvoir créer plusieurs éléments complexes, en dupliquant une partie de leurs données, et les associer à une information qui précédemment ne contenait qu’un seul de ces éléments, être en mesure de renseigner les parties manquantes et modifier les parties dupliquées, et supprimer un des éléments si nécessaire.

Proposition technique : Faire une story pour préparer la base de données pour pouvoir manipuler plusieurs éléments au lieu d’un seul, puis une story pour, via l’IHM, créer un nouvel élément à partir d’un élément existant et pouvoir le modifier ou le supprimer.

Alternative : Créer un bouton dans l’IHM pour ajouter à une information un élément non modifiable et dupliqué à 100 % à partir du précédent et simplement montrer en revue qu’au lieu de 1 élément, il y en a 2 après avoir appuyé sur le bouton, puis 3 après avoir appuyé une 2ème fois etc. Ce qui permet à l’équipe de se consacrer à la préparation de la structure de la base de données.

Conclusion

Et vous, avez-vous des exemples où vous avez réussi à éviter un découpage technique de vos story ?

2 réflexions sur « Bien découper les User Story »

  1. J’aime bien ton idée pour détecter un découpage technique : « S’ils doivent faire une opération que l’utilisateur ne sait pas faire… ». Excellent !

    Et effectivement, trop souvent, les équipes manquent d’inventivité et de créativité pour découper plus finement les User Story, pour qu’elles soient plus petites et plus incrémentales. L’exercice de l’Eléphant Carpaccio est excellent pour cela !

    Je constate également que tes exemples tournent beaucoup autour des bases de données. Depuis longtemps, j’ai constaté que c’est très souvent « la » partie problématique pour une équipe, malheureusement souvent à cause de manque de connaissances et d’outillages, notamment pour gérer automatiquement les évolutions des schémas…

    Merci Alex pour cet article !

Laisser un commentaire

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