Guide Scrum | 21. Erreurs de User Story

Les User Stories décrivent comment une nouvelle fonctionnalité d’un produit fonctionne dans un langage quotidien ou commercial. Cependant, leur préparation prend beaucoup de temps, d’efforts et de réflexion. Dans l’entrée d’aujourd’hui, nous soulignons les erreurs les plus courantes dans les User Stories et suggérons comment y remédier.

Les erreurs les plus courantes dans les User Stories – table des matières :

1. Introduction
2. Problèmes avec 3W
3. Problèmes avec 3C
4. Erreurs dans les User Stories – Résumé

Introduction

La User Story peut être un excellent outil pour motiver l’équipe à proposer de nouvelles solutions aux problèmes présentés du point de vue de l’utilisateur. Nous avons écrit sur ce qu’est une User Story dans une entrée séparée. Et dans cet article, nous avons introduit INVEST, qui est une méthode populaire pour rédiger de bonnes User Stories. Aujourd’hui, nous allons nous concentrer sur les erreurs dans les User Stories.

Problèmes avec 3W

Une User Story appropriée répond aux questions :

• Qui ? (Qui est l’utilisateur cible du produit ?)
• Quoi ? (Quelles capacités le produit a-t-il, et que peut-il faire ?)
• Pourquoi ? (Quel est son but ?)

Cependant, des problèmes peuvent accompagner les réponses à chacune de ces questions. Le problème le moins courant est le doute sur ce qui devrait changer dans le produit en réponse aux besoins du client. Par conséquent, nous allons nous concentrer sur les problèmes concernant Qui ? et Pourquoi ?

Qui – persona utilisateur

Une des erreurs les plus courantes lors de la création de User Stories est de ne pas répondre à la question de manière suffisamment précise : pour qui ? En d’autres termes, qui est l’utilisateur pour qui le changement prévu est destiné ?

Souvent, une réponse générique pointant vers le Client ou l’Utilisateur Final comme destinataire du changement n’est pas suffisante. La solution à ce problème est d’imaginer le destinataire comme une persona spécifique. Une persona est une image modèle du client cible. En d’autres termes, une persona est une représentation de la personne qui utilisera le produit d’une manière spécifique.

Après avoir analysé votre User Story, vous pourriez constater qu’elle raconte les histoires de différentes personnes en même temps. S’il y a de nombreux utilisateurs cibles, il vaut la peine de considérer de diviser la User Story en fragments plus petits pour éviter des actions contradictoires, mutuellement exclusives ou simplement inefficaces.

Pourquoi ? – un objectif mal défini

Parfois, la dernière section de la User Story devient la source de problèmes. Elle devrait spécifier la valeur commerciale des changements apportés lors de l’exécution de la User Story. Jetez un œil à un exemple d’erreurs dans les User Stories où la description d’une fonctionnalité supplémentaire remplace l’objectif :

En tant que client, je veux acheter une baguette magique d’un seul clic parce que je veux acheter un tapis volant la semaine prochaine.

Au lieu de donner la raison d’acheter la baguette magique, cette User Story ajoute un autre élément à la liste de courses du client potentiel. Par conséquent, lors de la préparation d’une User Story, n’oubliez pas les raisons des modifications dans la fonctionnalité du produit.

Problèmes avec 3C

Nous pouvons décomposer le processus de travail avec les User Stories en trois étapes appelées les 3C :

• Carte – La carte sur laquelle la User Story est enregistrée
• Conversation – Une conversation au sein de l’équipe Scrum à propos de la carte User Story
• Confirmation – définition des critères d’acceptation confirmant qu’une tâche a été complétée

Des erreurs peuvent survenir à chacune de ces étapes, que nous décrivons ci-dessous.

Carte

La carte mémoire qui stocke la User Story a une capacité limitée. Par conséquent, les problèmes les plus courants concernent la longueur et le volume de la User Story. La User Story a besoin de cohérence et de ne pas tourner autour du pot, comme on dit, à un degré si précis que chaque mot compte.

Cela est dû au fait que le problème de la carte User Story a deux dimensions. L’une est la manière dont elle est formulée : concise et contenant un minimum nécessaire d’énumération. La seconde est la taille réelle de la User Story. Une phrase générale peut exprimer un nombre énorme de tâches qui ne peuvent pas être complétées lors d’un seul Sprint.

Conversation

La formulation en une phrase de la User Story est le point de départ d’une conversation avec l’équipe de développement. Par conséquent, il est incorrect de la traiter comme une description de la tâche à réaliser. Cela empêche la possibilité de négociations et de discussions sur les différentes manières de sa mise en œuvre. La User Story ne doit pas être considérée comme une description des exigences pour une nouvelle fonctionnalité du produit, mais plutôt comme une invitation à commencer une conversation sur des solutions techniques spécifiques qui mèneront à la réalisation de la valeur commerciale définie par la User Story.

Confirmation

Nous avons écrit en détail sur les critères d’acceptation qui doivent être définis pour chaque User Story dans le texte décrivant ce qu’est une User Story. Cependant, une des erreurs courantes est le manque de clarté des critères de performance.

Une User Story bien écrite contient une description de la situation dans laquelle elle est mise en œuvre. Son test est que l’utilisateur profite de la nouvelle fonctionnalité créée par l’équipe de développement.

Un outil utile pour valider la User Story est de développer un test d’acceptation. Cela se trouve généralement de l’autre côté de la carte contenant la User Story.

Erreurs dans les User Stories – Résumé

Lors de la préparation et de l’application des User Stories, il vaut la peine de respecter les règles suivantes :

• Identifier précisément l’utilisateur affecté par le changement
• Définir clairement le but de la construction de nouvelles fonctionnalités du produit
• Garder son volume aussi court que possible
• Traiter la User Story comme un point de départ pour des discussions de solutions avec l’équipe de développement
• Établir des règles claires pour l’acceptation

Si vous aimez notre contenu, rejoignez notre communauté de travailleurs acharnés sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.