Bill Wake a mis au point la checklist INVEST en 2003, fournissant aux équipes un ensemble de directives simples à retenir pour rédiger des user stories convaincantes. Bien que ce soit lui qui en ait trouvé l’acronyme, c’est Mike Cohn qui a popularisé cette checklist dans son livre User Stories Applied: For Agile Software Development, publié en 2004.
Les user stories ont fait des adeptes au sein des équipes de développement tout en conservant un caractère informel. Elles sont rédigées sur des fiches ou des notes autocollantes pour faciliter la planification et la discussion, et font passer le fond et la fonction avant l’esthétique.
Aujourd’hui, les équipes de développement suivent l’acronyme INVEST pour rédiger des user stories exploitables :
- Independent : les user stories doivent être indépendantes les unes des autres. De cette façon, l’équipe peut les traiter dans n’importe quel ordre, avec un minimum de chevauchement ou de dépendance entre elles. Les user stories indépendantes permettent une priorisation, un développement et une livraison flexibles. Elles simplifient également la planification.
- Negotiable : les stories ne sont pas des cadres contractuels rigides, mais plutôt des bases de discussion. Leurs détails sont affinés collaborativement entre la ou le responsable produit et l’équipe de développement. Elles sont itératives et peuvent évoluer à mesure que l’équipe recueille des informations. Les user stories négociables favorisent le dialogue continu, permettant l’émergence des meilleures solutions. Elles évitent l’engagement prématuré vers des implémentations spécifiques.
- Valuable : le but ultime du produit que vous développez est d’apporter de la valeur ajoutée au public cible. Si une story ne procure pas de valeur, inutile d’y consacrer du temps. Les user stories utiles garantissent que les efforts de développement débouchent sur des résultats significatifs, évitant ainsi la création de fonctionnalités qui ne contribuent pas aux objectifs.
- Estimable : vous devez être en mesure d’estimer la taille d’une user story, afin que les tâches et la planification soient efficaces. Les user stories estimables facilitent la planification, la hiérarchisation et les prévisions. Si une story ne peut pas être estimée, elle doit probablement être rediscutée ou fragmentée.
- Small : les user stories doivent être suffisamment petites pour que l’équipe de développement puisse les programmer et les tester en une seule itération, généralement en trois jours. Elles favorisent un flux de travail régulier, permettent d’obtenir un feedback plus rapide, réduisent les risques et rendent les progrès plus visibles.
- Testable : chaque user story doit respecter un ensemble de critères permettant de déterminer si elle est prête ou nécessite des modifications. Les user stories testables aident l’équipe à savoir quand elle a « terminé » et si la fonctionnalité implémentée fonctionne comme prévu. Elles prennent en charge l’assurance qualité.
Le processus des 3C et les critères INVEST sont symbiotiques. La phase de discussion est essentielle pour s’assurer qu’une story est négociable et estimable. La phase de confirmation traite directement de l’aspect testable. La carte doit représenter quelque chose de suffisamment petit et indépendant pour faciliter une discussion ciblée et productive. Les équipes produit peuvent utiliser INVEST comme liste de contrôle qualité pendant les phases collaboratives des 3C.
Définissez des personas utilisateur.
L’utilisation de personas spécifiques au lieu d’utilisateurs et d’utilisatrices génériques améliore considérablement l’impact et la clarté des user stories. Les personas sont des représentations fictives créées à partir de recherches utilisateur pour identifier les différents types de personnes susceptibles d’interagir avec un produit. Ces profils aident les équipes à mieux comprendre leurs motivations, comportements et objectifs, et à renforcer l’empathie.
Pour créer des personas, les équipes mènent souvent des recherches par le biais d’enquêtes, d’entretiens et de groupes de discussion. Une fois définis, ces personas doivent être utilisés de manière cohérente dans la partie « En tant que [persona] » de la user story (par exemple, « En tant que Sarah, Marketing Manager », et non simplement « En tant que Manager »). Cette précision contribue à garantir que la story se concentre réellement sur les besoins d’un segment d’utilisateurs et d’utilisatrices bien connu.
Traitez les éléments clés des user stories.
Une user story bien conçue s’articule généralement autour de trois éléments fondamentaux, souvent exprimés dans une structure de phrase simple :
- Rôle : ce composant définit l’identité ou le persona d’un utilisateur ou d’une utilisatrice. Il est essentiel de saisir les motivations et les centres d’intérêt de la personne visée. L’utilisation de personas utilisateur bien définis à cette étape est très efficace pour créer des stories pertinentes et percutantes.
- Objectif : cette partie explique ce que l’utilisateur ou l’utilisatrice souhaite accomplir avec le produit ou la fonctionnalité spécifique. L’accent doit être mis sur la description de ses intentions et du résultat recherché, plutôt que sur les détails de l’implémentation ou des éléments d’interface.
- Avantage : cette clause cruciale explique pourquoi l’utilisateur ou l’utilisatrice veut atteindre l’objectif énoncé. Elle met en évidence la valeur, les avantages ou la motivation qui sous-tendent le besoin exprimé, en reliant la fonctionnalité à un objectif plus large et en justifiant l’effort de développement. Cette clause doit impérativement décrire une valeur métier ou utilisateur authentique, plutôt que des exigences système avec lesquelles certains besoins risquent d’être négligés.
