User story à partir d’un entretien : modèle et critères d’acceptation
Rédigez une user story à partir des propos d’un client, identifiez son besoin, conservez la source et ajoutez des critères d’acceptation. Exemple et modèle.
Une user story décrit un bénéfice utilisateur
Une user story décrit brièvement le résultat souhaité du point de vue de la personne qui utilisera le produit. On suit souvent le modèle « En tant que [rôle], je souhaite [action] afin de [bénéfice] ». Cette formulation ouvre la discussion sur le besoin. Il reste à définir les exigences et à vérifier le résultat.
« Ajoutez un bouton vert » est une solution proposée en entretien. Pour écrire la story, découvrez ce que la personne essaie de faire et ce qui la gêne dans le parcours actuel. Conservez la citation pour vérifier votre interprétation.
En tant qu’utilisateur, je veux un gros bouton d’export facile à utiliser.
En tant que coordinateur de projet, je souhaite transmettre certains points de la réunion à un collègue afin qu’il reçoive uniquement les décisions qui le concernent.
Comment rédiger une story à partir d’un entretien
Choisissez une situation concrète
Repérez le récit du dernier cas réel. Qui a agi, avec quel contenu et pour obtenir quoi ? Une remarque comme « tout le monde a besoin de rapports » ne suffit pas à justifier une story distincte.
Relevez les mots exacts et le contexte
Gardez le repère temporel et quelques phrases voisines. Distinguez les propos de votre interlocuteur de votre propre conclusion. Une situation exceptionnelle doit rester présentée comme telle.
Formulez le rôle, l’action et le bénéfice
Le rôle doit éclairer la situation, au-delà du terme générique « utilisateur ». L’action doit être observable et le bénéfice doit expliquer son utilité pour la personne.
Vérifiez le périmètre
Une story couvre un résultat utile et complet que l’on peut discuter et vérifier séparément. Évitez d’y englober tout le parcours, de l’inscription au rapport annuel.
Ajoutez des critères d’acceptation
Décrivez les conditions qui permettent de constater que le comportement attendu est en place. Couvrez le cas principal et une exception importante. Faites valider ces critères par l’équipe avant de les traiter comme des exigences.
Remettez les questions ouvertes en discussion
Si les droits d’accès, le volume des données ou le format du résultat restent inconnus, posez la question explicitement. Évitez de supposer que l’implémentation habituelle convient.
Des mots du coordinateur à la fiche de story
Après la réunion, j’envoie au développeur uniquement les tâches qui le concernent. Pour l’instant, je les copie à la main et j’ai peur d’emporter des commentaires internes.
L’exemple concerne un système fictif de gestion de notes et ne décrit aucune fonction actuelle de Transkribator. Le besoin est de partager un extrait précis sans données superflues. La couleur d’un éventuel bouton reste un choix de conception.
Story. En tant que coordinateur de projet, je souhaite regrouper certains points de la réunion dans un texte distinct afin de transmettre à la personne chargée du travail les seules décisions qui la concernent.
Critères proposés. Si trois points sont sélectionnés, le résultat contient exactement ces trois points. Avant l’envoi, le coordinateur voit l’intégralité du texte préparé. Si aucun point n’est sélectionné, le système demande d’en choisir.
Question ouverte. Le texte doit-il contenir des repères temporels ? Le sujet n’a pas été abordé en entretien. Nous le clarifierons lors de la prochaine discussion avant de le traiter comme une exigence.
La story est traçable, mais son importance pour la majorité des clients reste à établir. Un enregistrement rend compte d’une expérience. Pour établir la priorité, examinez d’autres éléments, les objectifs produit et le coût de mise en œuvre.
Distinguer une story d’une liste de tâches techniques
« Créer une table en base » ou « ajouter un gestionnaire d’événements » sont des tâches techniques. Elles peuvent servir à mettre en œuvre une story sans exprimer le bénéfice pour l’utilisateur. De même, une formulation soignée ne garantit pas que l’équipe a compris toutes les contraintes.
Expliquez la story à un testeur sans nommer de composant d’interface. Si vous ne pouvez pas décrire les gestes de la personne avant et après, reprenez l’entretien. Testez aussi les cas d’échec : absence de sélection, droits insuffisants ou nouvel essai. Gardez les exceptions déterminantes pour cette story et évitez de transformer la fiche en spécification complète du produit.
Fiche avec source et questions ouvertes
Titre de la story : Rôle et situation de travail : En tant que [qui], je souhaite [action] afin de [bénéfice]. Source : entretien / date / repère temporel : Citation d’origine : Notre interprétation : Critères d’acceptation : 1. Dans [condition], la personne peut [action] et obtient [résultat]. 2. Si [exception importante], [comportement attendu] se produit. Hors périmètre de la story : À clarifier : Formulation validée par et le :
- Le rôle est précis et le bénéfice est clair.
- La citation est distincte de la solution de l’équipe.
- Les critères sont vérifiables par observation.
- Les questions restent formulées comme telles.
Dans le détail
Faut-il toujours écrire « En tant que… je souhaite… afin de… » ?
La formule sert de repère. L’essentiel est que l’équipe comprenne qui agit, ce que la personne cherche à faire et pourquoi.
Combien de critères d’acceptation faut-il ?
Assez pour couvrir le scénario principal et les exceptions importantes. S’ils concernent plusieurs résultats indépendants, il peut être utile de scinder la story.
Un seul entretien suffit-il à formuler une story ?
Il permet de formuler une hypothèse en citant sa source. Il ne suffit pas à établir un besoin à l’échelle d’un segment ni à déclencher le développement.