Après avoir examiné et analysé plus de 10 000 user stories provenant de différentes sources, nous avons acquis un aperçu de ce qui représente une bonne user story. Si vous souhaitez apprendre à écrire de meilleures user stories, vous devriez trouver cet article utile.
Qu’est-ce qu’une user story ?
Avant de commencer les 10 étapes, revenons sur la question de ce qu'est une user story. Une user story est généralement décrite comme un espace réservé pour une conversation sur un besoin d’un utilisateur. Nous faisons généralement référence aux trois C : Carte, Conversation et Collaboration. Cependant, dans de nombreuses organisations, les user stories SONT la liste des exigences.
Les puristes agiles et les coachs diront généralement que la user story ne doit pas être considérée comme un substitut aux exigences écrites, car cela compromet la promotion de la collaboration entre les membres de l'équipe. Cependant, dans la plupart des cas dans la plupart des organisations, la liste des user stories est la liste des exigences.
Et maintenant, abordons 10 étapes pour rédiger de meilleures user stories :
1. Concentrez-vous sur les besoins fonctionnels
La fonctionnalité doit être écrite comme suit, dans la mesure du possible : En tant que __, je dois __ . Dans chaque histoire, incluez toutes les fonctionnalités qui la rendent complète. Incluez les mouvements de données entre les systèmes (à condition que votre objectif soit d'ajouter, de modifier ou de supprimer une telle fonctionnalité). Une user story qui commence par « Quand » au lieu de « En tant que » convient tant qu'elle décrit ensuite un événement fonctionnel comprenant un utilisateur, un objet et une action. par exemple "lorsque le capteur de température détecte 100 degrés, il envoie un signal pour désactiver la source de chaleur"
Excluez les tâches d'équipe et tout travail de configuration qui n'est pas directement lié à la fourniture de fonctionnalités nouvelles, modifiées ou supprimées.
2. Clair et sans ambiguïté
Si une user story n’est pas claire, cela entraînera des bugs. Il est absolument crucial de résoudre ce problème et de le résoudre rapidement. Il doit être sans ambiguïté pour le lectorat visé (au moins : utilisateurs, développeur, testeur, analyste, concepteur). Le test simple d'ambiguïté consiste à s'assurer que deux lecteurs du même texte parviennent à la même compréhension de la fonctionnalité qui doit être fournie – en cas de doute, demandez-leur.
Utilisez des verbes liés aux données tels que mise à jour, envoyer ou sauvegarder. Évitez les verbes tels que : considérer, fournir, vouloir, décider, soutenir et évaluer . Ceux-ci sont susceptibles d'induire le lecteur en erreur.
3. Des résultats précieux et traçables jusqu'aux résultats commerciaux
C’est à bien des égards l’attribut le plus important d’une user story. Si l’histoire n’est pas utile à l’entreprise, elle doit être exclue. Idéalement, la valeur de l'histoire peut être directement liée à Capacités et Résultats qui sont mesurables. c'est-à-dire qu'il existe une traçabilité claire entre la fonctionnalité de la user story et la capacité nécessaire pour réaliser l'activité mesurable résultat.
4. Du point de vue de l'utilisateur
Concentrez-vous sur l'expérience de l'utilisateur spécifique de l'application. Essayez également d'être précis sur le type et le contexte de l'utilisateur. Par exemple, au lieu de « en tant qu'utilisateur », essayez de donner du contexte dans vos noms d'utilisateur, par exemple : client_connecté, agent_marketing_connecté. administrateur_connecté. Ceci est informatif sur le contexte sans être verbeux.
5. Concis
Des user stories trop verbeuses qui incluent trop de détails sur les besoins fonctionnels, les déclarations de conception et les critères de test mèneront à la confusion. Gardez vos histoires court, simple et précis. Il vaut mieux être court et clair que d’être trop précis.
Essayez de garder vos user stories petites et simples tout en étant suffisamment globales pour éviter la prolifération des histoires. Deux conseils spécifiques consistent à faire référence aux objets et non aux types d'objet (trop gros) ou aux attributs d'objet (trop détaillés). Par exemple "en tant que client connecté, je peux mettre à jour mon profil » est mieux que "en tant que client connecté, je peux mettre à jour toutes les données » ou "En tant que client_connecté, je peux mettre à jour mon numéro de téléphone"
6. Cohérent
Soyez cohérent avec votre noms d'utilisateur et noms d'objets.
Avec les données conservées dans le système, soyez cohérents avec les noms que vous utilisez, essayez autant que possible de vous référer uniquement aux objets et aux types d'objets, évitez les attributs d'objet dans les histoires. par exemple profil de l'utilisateur (qui inclut un attribut pour la date de naissance) est meilleur que date de naissance.
7. Complet en soi
Si une user story nécessite plusieurs étapes fonctionnelles, incluez-les toutes. par exemple
Avant: En tant qu'utilisateur, je souhaite mettre à jour les détails du magasin.
Après: En tant qu'administrateur_connecté, je dois vérifier mon autorisation [pour mettre à jour le store_record]. Je peux alors mettre à jour le store_record
Les deux déclarations fonctionnelles indiquent que les autorisations doivent être vérifiées avant qu'une mise à jour puisse être effectuée.
8. CRUD Complet et non dupliqué sur un ensemble
Si nous mettons à jour magasin_informations dans l’exemple ci-dessus, existe-t-il également une user story similaire qui nous permet de créer une boutique ? Une autre histoire pour supprimer une boutique ? Et une autre histoire pour afficher un magasin ? Les histoires manquantes sont à l'origine d'une dérive de la portée, qui entraîne souvent des projets qui se poursuivent au-delà de leur calendrier initial.
De même, méfiez-vous des user stories dupliquées. Les exigences en double sont moins courantes, mais elles surviennent, alors vérifiez que vous n'avez pas doublé les fonctionnalités.
9. Testable
Si un lecteur ne peut pas facilement comprendre comment tester la user story, alors elle n'est pas testable. Nous faisons ici référence aux tests d’un point de vue fonctionnel. Toutes les contraintes doivent être incluses et toutes les contraintes scalaires doivent être quantifiées.
10. Ne contient aucun dessin
Les user stories ne doivent pas contenir de déclarations de conception.
Conclusion
Ce sont 10 de mes conseils préférés pour rédiger de meilleures user stories. Je vous garantis que si vous suivez ces conseils vous écrirez de meilleures user stories, et cela mènera à l'écriture meilleur logiciel.
Et si mes user stories ne sont pas bonnes ? Est-ce important, tant que j’ai l’essentiel de l’histoire ? Oui. Une seule ambiguïté entraînera une perte de temps et d’efforts en matière d’interprétation, une mauvaise interprétation et un certain degré de remaniement. Une omission pourrait nécessiter une révision majeure de la conception (ou introduire une dette technique s'il est trop tard pour modifier la conception). Alors oui, une grande prudence est de mise lors de la rédaction des user stories ou des exigences. De bonnes exigences peuvent conduire à une livraison à temps. De mauvaises exigences coûteront certainement plus cher et prendront plus de temps.
Besoin de plus
Découvrez cet excellent exemple concret de améliorer une user story.
