Un Guide Pour Écrire des Histoires d’utilisateurs Efficaces

Comment écrire des histoires d’utilisateurs efficaces?

Il y a 5 principes directeurs que je recommande de suivre:

1. Tout le monde devrait être heureux
   Obtenir tout le monde à bord est important, alors obtenez tous ceux qui vont écrire et utiliser vos histoires d’utilisateurs pour entrer leurs idées et d’accord sur le format que vous allez tous utiliser.
2. Soyez cohérent
   Une fois que vous avez une structure convenue, assurez-vous de vous y tenir.
3. Concentrez-vous sur ce qui est important
   Lorsque vous les écrivez, évitez les détails sans importance., Prenez le temps de les rendre concis, retirez toute gaufre car elle ne fait que gêner.
4. Aucun détail de mise en œuvre
   Toujours se concentrer sur le  » pourquoi « pas le”comment ». Pourquoi un utilisateur envie de quelque chose, pas, comment allons-nous construire. Si vous devez fournir des détails techniques, ceux-ci doivent être joints en tant que fichier de spécifications séparé.
5. Clair ,réalisable &testable
   Assurez-vous que tout le monde peut comprendre chaque histoire et qu’elle est réalisable dans le délai dont vous êtes satisfait. Si vous livrez en sprints de 2 semaines, cela ne devrait pas prendre plus de temps que ces 2 semaines.,

User story anatomy

Il y a 3 parties obligatoires à une user story, le titre, la description et les critères d’acceptation. Votre équipe peut convenir qu’une histoire utilisateur doit avoir d’autres champs avant de pouvoir commencer à travailler dessus. Par exemple, vous pouvez exiger un cessionnaire, des story points ou l’impact commercial, mais je considère que ceux-ci sont facultatifs car toutes les organisations n’en auront pas besoin.

Title
Les titres doivent être courts, uniques et non trompeurs.,

quelques bons exemples:

• « Ajouter un panneau de contact à la page d’accueil”
• « ajouter la prise en charge des cartes de débit au panier”
• « mettre à jour le marquage du modèle d’e — mail”

quelques exemples moins bons (malheureusement réels):

• « apporter des modifications convenues”
• « 32072 – mise à jour
• ”links — tracking query string for bill trigger and smart post install … »

description

la description détient la puissance réelle de l’histoire de l’utilisateur. Il devrait créer de l’empathie dans l’équipe pour l’utilisateur et une compréhension du problème à résoudre.,

Un très populaire de la structure de la description prend la forme de « Comme un … je veux … si je peux …”.

Cette structure pose la question de  » en tant que qui”? Qui est l’utilisateur confronté au problème? Vous pouvez référencer un personnage ici si vous les utilisez, sinon, donner un nom à l’utilisateur et Ajouter un contexte à la situation de l’utilisateur. Essayez d’éviter d’utiliser « Comme un client” ou « en tant Qu’utilisateur”, comme cela est moins efficace pour créer de l’empathie pour un utilisateur réel.

La description doit être rédigée dans un langage simple et clair, sans termes techniques ni abréviations., Vous devriez vous demander « Votre Nan peut-il le comprendre?” Un nouveau membre de l’équipe doit être capable de lire la description et de comprendre exactement quel est le problème qui doit être résolu.

Les exemples réels suivants sont tirés d’un projet visant à ajouter des fonctionnalités à un système de compte en ligne pour les clients d’une entreprise énergétique britannique.,

quelques bons exemples:

• « comme John, un client avec un compteur d’électricité traditionnel, je veux comprendre pourquoi je ne peux pas voir les graphiques de ma consommation d’énergie plus en détail que mois par mois afin que je puisse décider si je veux changer cela et obtenir un compteur intelligent installé. »
•  » En tant que Bart, un client de compteur traditionnel proactif voulant s’assurer que ma prochaine facture est exacte, je veux savoir si un relevé de compteur a déjà été soumis aujourd’hui et que je n’ai pas besoin d’en soumettre un autre., »

Quelques exemples moins bons:

• ”En tant qu’utilisateur, je veux empêcher les clients trad de pouvoir descendre en dessous du niveau le plus élevé afin que leur expérience client soit gérée »
•  » En tant que client qui a fourni un compteur lu aujourd’hui ou dont une lecture de carburant a été estimée aujourd’hui, je ne devrais pas être autorisé à soumettre un autre compteur lu aujourd’hui car SAP ne peut pas accepter plus d’un compteur lu par carburant et par jour. »

Les exemples les moins bons ont en fait été réécrits pour être les bons exemples ci-dessus car les problèmes qu’ils ont décrits n’étaient pas clairs., Ce processus de raffinement doit être effectué chaque fois qu’une partie d’une histoire utilisateur n’est pas claire. Assurez-vous simplement que tout le monde dans l’équipe est au courant et accepte les modifications.

les critères d’Acceptation

les critères d’Acceptation sont utilisés pour prouver l’intégralité de l’article de l’utilisateur. C’est utile pour les développeurs et les testeurs.

Écrire les critères d’acceptation est un moyen efficace de parcourir tous les détails de l’histoire avant de commencer tout travail. De nombreux pièges potentiels ou travaux inattendus peuvent être « découverts” tôt en écrivant de bons critères d’acceptation.,

une structure très populaire pour les critères d’acceptation prend la forme de « donné When quand Then alors Then” comme on le voit dans les exemples ci-dessous.

si une histoire d’Utilisateur a plus de 10 critères d’acceptation, cela peut être une indication que l’histoire fait trop de choses. Dans ce cas, je recommande d’envisager de diviser l’histoire.

toute l’équipe devrait être impliquée dans la rédaction des critères d’acceptation. Si ce n’est pas possible, je recommande fortement à tout le monde de les lire et de les accepter avant de travailler dessus. Cela est particulièrement vrai de toute personne impliquée dans le test du travail.,

la numérotation des critères d’acceptation facilite leur référence.

quelques bons exemples:

1. donné un client avec un compteur traditionnel sur le graphique à barres de consommation d’énergie
   lorsque vous cliquez sur l’outil-astuce pendant un mois
   alors un popup est affiché correspondant à la conception spécifiée.
2. étant donné qu’un client à double carburant consulte le graphique à barres de consommation d’énergie
   lorsqu’il a des mois avec des valeurs estimées
   alors la légende du graphique doit clairement montrer une icône d’électricité estimée avec une barre rouge clair
   alors la légende du graphique doit clairement montrer une icône de gaz estimée,

Lorsque nous n’avons pas besoin d’user stories

Tâches techniques

Parfois, une tâche technique ne semble pas être liée à un client. Si tel est le cas, n’utilisez pas de user story. Mais il vaut toujours la peine de se demander pourquoi vous effectuez une tâche technique; mettez-vous à niveau une bibliothèque pour améliorer la vitesse pour les utilisateurs? Si c’est le cas, cela devrait être une histoire d’utilisateur.

Bogues

Si un bogue est trouvé lors du test d’une histoire utilisateur en cours de travail, il doit être associé à cette histoire utilisateur.,

Si un bug est trouvé pour quelque chose qui n’est pas un utilisateur actuel de l’histoire, alors il ne devrait pas être associés à un article de l’utilisateur, mais ajouté à la file d’attente comme un travail indépendant.

l’amélioration Continue

l’Utilisateur histoires évoluera plus appris sur le travail à faire. C’est bien, continuez à les améliorer jusqu’au point où vous libérez le travail aux utilisateurs., Assurez-vous simplement que tous les membres de votre équipe sont au courant et acceptent les modifications apportées.

Continuez à affiner le processus. Soyez agile, réfléchissez à la façon dont vos user stories fonctionnent pour votre équipe, discutez-en dans retros et continuez à améliorer votre façon de les écrire.