Guide de mêlée | 21. Erreurs de User Story

Les témoignages d'utilisateurs décrivent le fonctionnement d'une nouvelle fonctionnalité de produit dans le langage courant ou professionnel. Cependant, leur préparation demande beaucoup de temps, d'efforts et de réflexion. Dans l'entrée d'aujourd'hui, nous soulignons les erreurs les plus courantes de la User Story et suggérons comment les traiter.

Les erreurs les plus courantes de User Story – table des matières :

1. Introduction
2. Problèmes avec 3W
3. Problèmes avec 3C
4. Erreurs de User Story – Résumé

Introduction

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 la User Story dans une entrée séparée. Et dans cet article, nous avons présenté INVEST, qui est une méthode populaire pour écrire de bonnes User Stories. Aujourd'hui, nous allons nous concentrer sur les erreurs de User Story.

Problèmes avec 3W

Une véritable User Story répond aux questions :

• Qui? (Qui est l'utilisateur cible du produit ?)
• Quoi? (Quelles sont les capacités du produit et que peut-il faire ?)
• Pourquoi? (A quoi est-ce que ça sert?)

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 doit changer dans le produit en réponse aux besoins du client. Par conséquent, nous nous concentrerons sur les problèmes concernant Qui ? et pourquoi?

Qui - Persona de l'utilisateur

L'une des erreurs les plus courantes commises lors de la création de User Stories est de ne pas répondre assez précisément à la question : pour qui ? En d'autres termes, quel est l'utilisateur à qui est destiné le changement prévu ?

Souvent, une réponse générique désignant le client ou l'utilisateur final comme le destinataire de la modification ne suffit pas. La solution à ce problème est d'imaginer le destinataire comme un personnage spécifique. Un persona est une image modèle du client cible. En d'autres termes, un 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 constaterez peut-être 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 d'envisager 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. Il doit spécifier la valeur commerciale des modifications apportées lors de l'exécution de la User Story. Jetez un œil à un exemple d'erreurs de User Story où la description de fonctionnalités supplémentaires remplace l'objectif :

En tant que client, je souhaite acheter une baguette magique en un clic car je souhaite acheter un tapis volant la semaine prochaine.

Au lieu de donner la raison de l'achat de la baguette magique, cette User Story ajoute un autre article à 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 de 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é accomplie

Des erreurs peuvent survenir sur l'un d'entre eux, 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, à tel point que chaque mot compte.

En effet, le problème de la carte User Story a deux dimensions. L'un est la façon dont il est formulé : concis et contenant le minimum nécessaire d'énumérations. La seconde est la taille réelle de la User Story. Une phrase générale peut exprimer un grand nombre de tâches qui ne peuvent pas être complétées au cours 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 le traiter comme une description de la tâche à effectuer. Il désactive la possibilité de négociations et de discussions sur les différentes modalités de sa mise en œuvre. User Story ne doit pas être traitée comme une description des exigences pour les nouvelles fonctionnalités du produit, c'est plutôt une invitation à entamer une conversation sur des solutions techniques spécifiques qui conduiront à la réalisation de la valeur commerciale définie par User Story.

Confirmation

Nous avons décrit en détail 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. L'une des erreurs courantes, cependant, est le manque d'imprécision des critères de performance.

Une User Story bien rédigée 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 de User Story – Résumé

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

• Identifier précisément l'Utilisateur concerné par le changement
• Définir clairement l'objectif de la création de nouvelles fonctionnalités du produit
• Gardez son volume aussi court que possible
• Traiter la User Story comme un point de départ pour les discussions sur la solution avec l'équipe de développement
• Établir des règles claires pour l'acceptation

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit