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.
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.
Une User Story appropriée répond aux questions :
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 ?
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.
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.
Nous pouvons décomposer le processus de travail avec les User Stories en trois étapes appelées les 3C :
Des erreurs peuvent survenir à chacune de ces étapes, que nous décrivons ci-dessous.
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.
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.
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.
Lors de la préparation et de l’application des User Stories, il vaut la peine de respecter les règles suivantes :
Si vous aimez notre contenu, rejoignez notre communauté de travailleurs acharnés sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
En tant que chef de projet, Caroline est une experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.
Les entreprises luttent pour gérer une vaste quantité de contenu publié en ligne, des publications…
À l'ère de la transformation numérique, les entreprises ont accès à une quantité sans précédent…
Saviez-vous que vous pouvez obtenir l'essence d'un enregistrement de plusieurs heures d'une réunion ou d'une…
Imaginez un monde où votre entreprise peut créer des vidéos engageantes et personnalisées pour n'importe…
Pour tirer pleinement parti du potentiel des grands modèles de langage (LLMs), les entreprises doivent…
En 2018, Unilever avait déjà entrepris un voyage conscient pour équilibrer les capacités d'automatisation et…