Dans sa série de nouvelles en prévision de la rentrée, Mike Cohn de Mountain Goat Software a abordé un problème fréquent : « Comment présenter des user stories à votre équipe ? »

Astuce #1: Commencez par quelques définitions.

Une user story (ou histoire utilisateur) décrit quelque chose qu’un utilisateur veut. L’histoire suit généralement ce modèle: « En tant que [type d’utilisateur], je [veux, j’ai besoin ou je suis obligé de faire cette chose] afin que [je puisse atteindre cet objectif]. »

Une epic (ou épopée) est une grande user story. Voilà. Rien de plus, rien de moins.

Un thème est une collection d’histoires utilisateurs connectées entre elles. Certaines personnes ont introduit le terme de feature (fonctionnalité) pour désigner une histoire utilisateur suffisamment grande pour être livrée ou peut-être assez grande pour que les utilisateurs la remarquent et soient plus heureux.

Toutes ces définitions ne sont utiles que si elles simplifient la discussion sur le produit que vous développez. Pour en savoir plus sur comment et pourquoi utiliser ces termes (et pourquoi les outils ont ajouté à la confusion), consultez Epics, Features et User Stories.

Astuce #2: Ajoutez le bon niveau de détails au bon moment.

Comme Boucle d’or et les trois ours, nous ne voulons pas d’articles dans l’arriéré de produits avec trop peu ou trop de détails. Nous voulons juste le bon niveau de détails.

Si un Product Owner écrit une user story qui inclut trop peu de détails, les développeurs n’en sauront pas assez lors de la planification du sprint pour comprendre ce qu’il faut construire. Lorsque des détails excessifs sont inclus, le temps et l’argent dépensés à ajouter ces détails inutiles sont gaspillés.

Il est peu probable que le product backlog (l’arriéré de produit) d’une équipe soit parfaitement détaillé dès le départ. Cela signifie que l’équipe devra probablement itérer pour aller vers la bonne quantité de détails.

Je trouve qu’il est beaucoup plus facile pour les membres de l’équipe de trouver le bon équilibre lorsqu’ils commencent avec trop peu de détails. Commencez donc par remplir le modèle d’histoire utilisateur avec le strict minimum de fonctionnalités et de détails du produit, et partez de là.

Astuce #3: Apprenez la méthode SPIDR pour découper les histoires

SPIDR : Spike, Path, Interfaces, Data, and Rules. (Spike*, chemin, interfaces, données et règles). Vous pouvez lire sur chaque technique et obtenir une affiche SPIDR gratuite ici.

L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper les histoires utilisateurs. Je parie que vous avez eu du mal avec cela, parce que je l’ai certainement connu au début. C’est pourquoi j’ai trouvé un acronyme facile à retenir pour détailler les cinq facteurs différents qui pourraient vous aider à diviser une histoire.

J’espère que ces conseils vous aideront, vous et votre équipe, à réussir avec agile,

P.S. Il ne vous reste que deux chances d’assister à un cours Better User Stories en direct avec Mike avant la fin de l’année. https://www.mountaingoatsoftware.com/training/courses/better-user-stories

---

* Spike : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.