Comment rédiger des user stories agiles: 7 directives

Fondamentalement, les user stories agiles sont des outils courts et simples pour documenter une action ou une intention unique souhaitée par l'utilisateur ciblé pour atteindre un objectif. Les user stories les plus simples ont un format, «En tant que type ou rôle d'utilisateur , je veux agir ou intenter  pour cette raison ou cet avantage » qui répond à au moins trois questions simples sur qui, quoi et pourquoi l'histoire est dans la file d'attente du backlog.

À mesure que les équipes mûrissent et que les organisations utilisent l'agilité dans plusieurs équipes et initiatives, les user stories agiles prennent souvent beaucoup plus de définition et de structure pour garantir une compréhension commune de l'intention et des exigences sous-jacentes.

Commencer à écrire des user stories agiles

Il existe de nombreuses ressources pour aider les nouveaux propriétaires de produits, les analystes commerciaux, les Scrum Masters et les responsables techniques à comprendre les bases de la rédaction de user stories. Certains endroits pour commencer incluent des articles d'Atlassian, FreeCodeCamp, Agile Modeling et ces 200 exemples de user story. L'un des écrits les plus complets est celui de la meilleure user story agile d'Alexander Cowan. Il existe des livres sur l'écriture d'histoires, notamment User Story Mapping  de Jeff Paton et Peter Economy et User Stories Applied  par Mike Cohn. Vous pouvez également suivre des cours sur l'écriture d'histoires d'Udemy, Learning Tree, VersionOne et Lynda.

Un principe fondamental partagé d'abord par Bill Wake est d' investir dans de bonnes histoires . Invest  signifie «indépendant, négociable, précieux, estimable, petit et testable», ce qui constitue une bonne liste de contrôle pour les auteurs d'histoires agiles. «Un guide du leader agile pour rédiger des user stories» est un article qui explique comment appliquer les principes d' investissement  .

Les bases sont relativement simples, mais j'entends et suis souvent témoin de déconnexions entre les parties prenantes, les propriétaires de produits, les développeurs et les testeurs autour de la qualité des exigences ou de la réalité d'une histoire. Il y a parfois des points de vue contradictoires sur le niveau de détail requis, où s'adapter aux exigences techniques et quels artefacts doivent être créés avec les user stories.

Avec ces questions à l'esprit, voici sept directives au-delà des bases sur l'écriture de user stories agiles.

1. Écrivez des histoires pour le public qui les utilisera

Avant d'écrire des histoires, gardez à l'esprit que les histoires sont destinées à être lues et comprises par des personnes participant au processus de développement avec des besoins et des responsabilités différents. Les auteurs et les contributeurs doivent garder le public à l'esprit et rédiger des articles pour répondre aux besoins collectifs:

  • Les propriétaires de produit ne sont peut-être pas ceux qui rédigent les histoires, en particulier si votre organisation délègue cette fonction aux analystes commerciaux ou si plusieurs personnes sont impliquées dans la rédaction de l'histoire. Les propriétaires de produit veulent s'assurer que l'histoire capture pleinement les besoins et l'intention de l'utilisateur. Ils doivent lire les critères d'acceptation détaillés, mais ne veulent pas nécessairement s'enliser dans les détails techniques de la mise en œuvre. Les propriétaires de produits doivent également comprendre comment l'histoire s'aligne sur la situation dans son ensemble, ils doivent donc s'intéresser activement à la manière dont les épopées et les fonctionnalités sont définies et à la manière dont les histoires leur sont attribuées.
  • Les parties prenantes ne liront pas les détails de l'histoire, mais exploreront les épopées et liront le résumé de l'histoire. Si vous avez de nombreuses parties prenantes, envisagez d'utiliser un format descriptif pour les résumés et de déplacer la description «En tant que type d'utilisateur ou rôle » au début de la description de la user story.
  • Les responsables techniques sont souvent la première personne de l'équipe à examiner les histoires, et ils étudieront les exigences pour voir si une histoire est trop grande et devrait être divisée en plusieurs histoires, ou voir si l'histoire nécessite un travail technique préalable pour déterminer la meilleure. Solution.
  • Le cessionnaire est la personne responsable d'examiner les détails et de faire rapport sur les progrès lors des réunions quotidiennes. Les assignés doivent examiner les histoires pour les dépendances qui peuvent devenir des blocs pendant le sprint.
  • Les membres de l'équipe examinent souvent toutes les histoires pour comprendre leurs histoires assignées dans le contexte des autres histoires assignées au sprint.
  • Les testeurs déterminent s'il existe des lacunes ou des risques non identifiés dans les critères d'acceptation, puis examinent la meilleure façon de les mettre en œuvre dans des cadres de test automatisés.
  • L'analyste de l'équipe, qui peut être un gestionnaire de programme ou un membre du bureau de gestion de projet, souhaite que les histoires soient entièrement étiquetées et catégorisées afin que des mesures significatives puissent être extraites du backlog.

2. Commencez en pensant à l'utilisateur

Bien que les user stories agiles puissent nécessiter de nombreux détails, il est très important de commencer avec l'utilisateur à l'esprit. L'histoire devrait être de définir ce que  l' action ou l' intention que l'utilisateur souhaite accomplir et pourquoi  cette répond à un besoin, une valeur fondamentale, ou un but provenant de l'expérience.

Pour les applications plus complexes, la définition de différents personnages d'utilisateurs qui illustrent les besoins, les valeurs et les modèles d'utilisation de différents types d'utilisateurs est une discipline importante et peut améliorer l'écriture d'histoires. Dans «10 conseils pour rédiger de bonnes user stories», Roman Pichler suggère que «les objectifs persona vous aident à découvrir les bonnes histoires. Demandez-vous quelles fonctionnalités le produit doit fournir pour atteindre les objectifs des personas. » L' utilisation de Personas pour renforcer les objectifs de l' utilisateur fournit un sens plus riche pourquoi une histoire est importante et contribue à établir des priorités de l'arriéré.

3. Expliquez pourquoi l'histoire est importante

Comprendre, documenter et discuter des besoins des utilisateurs ou des objectifs de la personnalité de l'utilisateur n'est qu'une dimension qui explique pourquoi le propriétaire du produit donne la priorité aux histoires. L'histoire doit également fournir une valeur commerciale, ce qui est difficile à quantifier mais qui peut être qualifiable  au niveau de l'histoire, de la fonctionnalité, de l'épopée ou de la version.  

Répondre aux raisons  peut être important pour les développeurs lorsqu'ils sont habilités à proposer différentes options de mise en œuvre. Par exemple, une fonctionnalité qui améliore l'expérience de connexion des utilisateurs peut également profiter à l'entreprise si la nouvelle expérience génère également de meilleures données client. Un développeur peut réfléchir à cette valeur ajoutée commerciale et optimiser la mise en œuvre pour cet objectif même si les critères d'acceptation de l'histoire ne sont pas spécifiques à cette exigence.

4. Définir les critères d'acceptation sans prescrire de solution

La discipline la plus importante sur laquelle se concentrer dans la rédaction de l'histoire est la rédaction des critères d'acceptation. Il s'agit souvent de listes à puces de courtes déclarations de réussite ou d'échec qui documentent les exigences, les contraintes, les mesures et les attentes. Ces critères d'acceptation sont souvent utilisés de plusieurs manières:

  • Les responsables techniques et les équipes les utilisent pour estimer les points d'histoire en fonction de la complexité et des efforts.
  • Les développeurs restreignent les options de mise en œuvre à celles qui répondent aux critères d'acceptation.
  • Les propriétaires de produits peuvent réduire la portée ou la complexité des critères d'acceptation pour conduire des implémentations avec des estimations inférieures.
  • Le cessionnaire communique des blocs ou des problèmes répondant à des critères difficiles lors des standups.
  • Les ingénieurs d'assurance qualité utilisent des critères d'acceptation pour développer des tests automatisés.
  • Le propriétaire du produit passe en revue les critères clés pendant la démo agile pour s'assurer que l'histoire est terminée .

Écrire des critères d'acceptation n'est pas anodin. Les critères d'acceptation des critères d'acceptation mettent en évidence certains problèmes tels que la fourniture d'un trop grand nombre de critères, la définition de critères trop vagues ou la documentation de critères complexes qui ne peuvent pas être facilement vérifiés. Certains rédacteurs utilisent des modèles de critères d'acceptation qui définissent une structure pour des critères courts, atomiques et testables.

5. Utilisez des histoires pour définir quoi et pourquoi; définir des tâches sur la façon de mettre en œuvre

L'une des erreurs critiques que je constate que les équipes commettent lors de l'écriture d'histoires est d'être verbeux et précis autour de la mise en œuvre. Ces histoires mal écrites investissent beaucoup d'efforts à décrire la façon de mettre en œuvre souvent au détriment de décrire ce que l'utilisateur a besoin, pourquoi  il répond à leurs objectifs, et où  il entraîne une valeur commerciale.

Cela peut se produire pour plusieurs raisons.

Les propriétaires de produits inexpérimentés peuvent utiliser des histoires pour peindre leurs visions de mise en œuvre. En d'autres termes, ils peuvent trop spécifier la conception de l'utilisateur et les implémentations fonctionnelles au lieu de partager l'expérience et les avantages de l'utilisateur cible. Certains propriétaires de produit confondent leur conceptualisation de la façon dont quelque chose pourrait  fonctionner (le processus par lequel ils parviennent à comprendre les exigences) avec la façon dont cela devrait  fonctionner, transformant accidentellement un exemple d'implémentation interne en spécification d'implémentation externe.

D'autres propriétaires de produit peuvent dépasser leurs limites en demandant à l'équipe de «me construire ça». C'est l'un de mes 20 mauvais comportements de Product Owner, pour lequel j'ai des recommandations aux Product Owner sur la collaboration avec l'équipe autour de solutions.

L'autre raison pour laquelle les histoires peuvent devenir encombrées de détails de mise en œuvre est que certaines équipes et responsables techniques veulent ce niveau de détail. Les équipes techniques nouvellement formées travaillant à l'amélioration des applications existantes peuvent souhaiter ce niveau de détail jusqu'à ce qu'elles comprennent mieux le fonctionnement de l'application et comprennent pleinement les besoins des utilisateurs. Certaines équipes réparties travaillant avec des développeurs offshore ou des pigistes peuvent également vouloir documenter les détails de la mise en œuvre pour s'assurer que ces membres comprennent leurs responsabilités.

Pour ces équipes, la meilleure chose à faire est de créer un lien vers des diagrammes d'implémentation et de documenter qui fait quoi et comment en tant que tâches liées à l'histoire. La plupart des outils de gestion agile permettent des tâches ou des sous-tâches, et ce niveau de détail est généralement séparé du corps de l'histoire. Un diagramme dans cet article illustre bien ce principe important d'utilisation d'histoires agiles pour décomposer les expériences utilisateur et les processus métier et l'ajout de tâches pour définir la mise en œuvre à des éléments de travail individuels.

6. Marquez vos histoires pour générer des analyses et des améliorations pratiques

Une fois les histoires écrites, travaillées et complétées, de nombreuses équipes cherchent à capturer des mesures et à effectuer des analyses qui peuvent améliorer les processus ou utilisées pour réaliser des analyses de rentabilisation pour un investissement supplémentaire.

Voici quelques exemples:

  • Étiquetez les histoires comme une dette technique pour quantifier la taille de la dette, le pourcentage de la vitesse de l'équipe utilisé pour y remédier et la dette totale complétée à chaque version.
  • Définissez des histoires de pics fonctionnels et techniques pour stimuler l'expérimentation et l'innovation, puis indiquez où cela a un impact commercial.
  • Si votre équipe estime les user stories agiles, demandez à l'équipe de marquer les stories à la fin du sprint pour signaler si elles ont surestimé ou sous-estimé afin d'améliorer la précision des estimations.
  • Utilisez des étiquettes, des composants et des champs personnalisés pour faciliter la recherche dans le backlog des interprétations ou métriques historiques. Par exemple, savoir quelles histoires ont eu un impact sur les API ou quelles exigences ont conduit aux dernières améliorations fonctionnelles d'un domaine spécifique de l'application peut être fait lorsque les histoires sont étiquetées avec des composants fonctionnels et techniques.
  • Marquer les histoires collectant ou traitant des informations sensibles telles que des informations personnelles identifiables (PII), des transactions de commerce électronique ou des données réglementées par l'industrie telles que des données HIPAA pour permettre des examens de sécurité et de conformité.
  • Fournissez des commentaires au propriétaire du produit et à l'équipe. Au-delà du marquage d'une histoire terminée , un propriétaire de produit pourrait également fournir des commentaires à l'équipe, par exemple en reconnaissant un excellent travail . De même, l'équipe peut fournir des commentaires au product owner sur la qualité globale et l'interprétabilité d'une user story.

7. Définissez des modèles d'histoires agiles et des guides de style

Les grandes organisations travaillant avec plusieurs équipes agiles et propriétaires de produits peuvent souhaiter rédiger des normes et des guides de style pour la rédaction d'histoires. La cohérence aide les nouveaux propriétaires de produits à acquérir plus rapidement les compétences en écriture et améliore également l'efficacité des membres de l'équipe à consommer les informations.

Une autre raison de concevoir des modèles d'histoires est que différents types de produits et d'applications se prêtent à différentes expressions et artefacts de user story. Quelques exemples:

  • Les histoires de processus métier peuvent nécessiter des liens vers des diagrammes de flux de travail et également spécifier des rôles et des autorisations.
  • Les histoires d'applications destinées aux clients doivent avoir des liens vers des wireframes et inclure des critères de performance.
  • Les histoires d'API doivent documenter les modèles d'utilisation et les métriques attendus.
  • Les histoires de Business Intelligence et de visualisation de données doivent fournir des directives sur les champs et informations nécessaires à l'analyse demandée.

Les modèles aident à relier la communication entre les équipes et les chefs de produit sur ce sur quoi se concentrer lors de l'écriture d'histoires agiles.

Et n'est-ce pas le but des histoires agiles? Les pratiques, directives et principes de rédaction d'histoires agiles sont là pour aider les équipes à savoir ce qui est important pour les utilisateurs et pour l'entreprise avant de réfléchir à la manière de les mettre en œuvre.