Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ?

The Magic of Small User Stories

https://www.agilealliance.org/the-magic-of-small-user-stories/ par Dwight Kingdon

J’ai souvent rencontré des équipes qui aiment les longues Histoires Utilisateur. Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ?  Les histoires plus grosses signifient une meilleure efficacité, non ?  Pas nécessairement.

Pourquoi des histoires plus courtes ?

• 

  Focus : Des histoires courtes nous focalisent et nous aident à voir que la fin n’est pas trop éloignée. Il est fréquent de se sentir écrasé par les détails quand nous travaillons sur de longues histoires.  De brèves histoires génèrent aussi une satisfaction de l’équipe plus élevée; les personnes reçoivent une petite dose de dopamine à chaque fois qu’elles finissent quelque chose.

• Transparence : Des histoires courtes fournissent une transparence et une visibilité beaucoup plus claire des progrès dans le sprint pendant le Daily Stand-Up.  Le réalisé est facile à suivre quand nous voyons une série de courtes histoires achevées; il est plus difficile d’évaluer et de visualiser le réel progrès sur une grande histoire chaque jour.

• 

  Prévisibilité : Des histoires courtes ont tendance à aboutir vélocité plus précise et juste, ce qui réduit la variabilité et améliore la prévisibilité.  Des évaluations relatives de points d’histoire en utilisant la séquence de Fibonacci sont par définition de moins en moins précises pour de plus grandes histoires – voir “le cône d’incertitude”.  Ainsi, une histoire 13 ou à 20 points est probablement beaucoup moins prévisible que plusieurs histoires à 2, 3, ou 5 points.

• Flexibilité : Des histoires courtes fournissent .  Elles fournissent davantage de flexibilité pour nous adapter comme nous apprenons.  Quand les circonstances changent ou que certaines histoires deviennent sans utilité, il y a moins de perte dans la réorganisation ou l’élimination d’une courte histoire.

• Livraison : Des histoires courtes permettent aux équipes de test de commencer à évaluer plus tôt dans le sprint et de travailler sur de plus petites portions de code.
• Risque Réduit : Des histoires volumineuses augmentent le risque que l’équipe ne livre rien à la fin du sprint qui soit 100 % fait (Done).  La capacité de l’équipe ressemble à un entonnoir.  Quand nous essayons de forcer un grand objet (de grandes histoires) à y passer, l’entonnoir se bouche.  Par exemple, un développeur travaillant sur une grande histoire peut aussi être le seul avec le jeu de compétences nécessaires pour compléter une autre histoire critique.

Comment puis-je créer des histoires plus courtes ?

Vous trouverez des tas de bons articles sur la décomposition d’histoires d’utilisateur sur Google.  Néanmoins, voici une poignée de questions que j’ai trouvé utiles pour déterminer comment créer des histoires plus courtes :

• 

  S’il y a plusieurs résultats dans une unique histoire utilisateur, sont-ils tous nécessaires tout de suite ? Y-a-t-il un découpage 80/20 qui fournirait la majeure partie de la valeur ?  Pouvez-vous développer ces 20 % dans une autre histoire différente ?

• Avez-vous des règles métier multiples ou plusieurs personas dans l’histoire utilisateur ? Ces règles métier peuvent-elles être construites séparément, ou les différents personas traités dans des histoires séparées ?  Des règles métier plus simples peuvent-elles suffire pour le moment pour faire marcher la solution ?
• Est-ce que le parcours optimal peut être codé en premier sans toutes les exceptions ?  Ces exceptions peuvent souvent être relogées dans des histoires complémentaires.
• Y-a-t-il de multiples plates-formes ou plusieurs interfaces utilisateur associées à l’histoire utilisateur ? Pouvons-nous les développer une par une ?
• Des opérations multiples sont-elles contenues dans l’histoire utilisateur c’est-à-dire  Créer, mettre à jour, supprimer une donnée? Pouvons-nous développer une opération à la fois ?
• Quels scénarios de test s’appliquent ? Certains scénarios sont-ils complexes et pas très critiques ?  Une première itération plus simple peut-elle être développée pour valider le design ?
• La plupart de la complexité de l’histoire vient-elle d’exigences non-fonctionnelles comme la sécurité ou la performance ?  Si c’est le cas, l’histoire peut-elle être découpée pour d’abord faire le travail sur la fonctionnalité, puis modifiée plus tard pour satisfaire ces exigences non-fonctionnelles ?

Combien courte est « courte » ?  Quelle est la bonne taille ?

Ce sont des questions très subjectives et elles dépendent de plusieurs facteurs dont la capacité de l’équipe, la durée de sprint et autres.  Un bon point de départ pour déterminer la taille idéale de l’histoire doit utiliser l’acronyme I.N.V.E.S.T.  Si vous êtes peu familiers avec cette approche, cherchez simplement “agile invest” sur votre navigateur internet pour en apprendre davantage.  Une histoire doit délivrer la valeur.  Livrer une histoire qui a peu de bénéfices perceptibles juste pour la garder petite n’a probablement aucun sens.  Au final, les histoires utilisateur plus courtes sont d’habitude meilleures que de plus longues.  Mais, le bon sens s’applique pour vous assurer qu’une histoire utilisateur peut livrer une réelle valeur et peut aussi être achevé en un unique sprint.