Rédiger une User Story : les bonnes pratiques

 

Une User Story est une description simple et compréhensible d’une fonctionnalité à valeur business d’un système. Généralement, une User Story respecte la syntaxe suivante :

En tant que  ,  je veux … dans le but de …

Exemple : En tant que client, je veux pouvoir consulter les commentaires sur les hôtels afin de choisir l’hôtel qui me convient.

Plus qu’une phrase ?

La rédaction d’une User Story se fait en trois étapes incrémentales appelées les 3C (Card, Conversation and Confirmation). Ces étapes assurent :

  • Une description du besoin;
  • Une négociation en vue d’une définition du besoin;
  • Une définition des critères d’acceptabilité.

Une bonne User Story doit aussi respecter les caractéristiques réunies sous le sigle INVEST :

  • Indépendante : assure l’indépendance d’une User Story vis-à-vis des autres user stories du backlog;
  • Négociable : une User Story doit être un support de discussion en vue d’une amélioration du besoin initial;
  • Valorisable : la réalisation d’une User Story doit rendre un service à l’utilisateur. En un mot, une User Story n’a de sens que si elle apporte une valeur métier;
  • Estimable : une User Story doit être bien définie pour être facilement chiffrable;
  • Suffisamment petit : une User Story doit être réalisable sur un sprint;
  • Testable : une User Story  doit être accompagnée de ces critères d’acceptabilité pour faciliter sa validation.

Sans titre

Que faire à chaque étape ? Quelles bonnes pratiques adoptées ? Que faut –il éviter ?

Présenter une vision utilisateur  autour de trois axes : rôle, besoin et valeur métier
Une User Story doit exprimer un point de vue utilisateur plutôt qu’un point de vue système ou tout autre. Ce point de vue est guidé par la réponse à ces trois questions :

  • Qui a fait la demande ou qui bénéfice de la demande ? (rôle utilisateur);
  • Quelle est la demande ? (besoin);
  • Quelle valeur métier découle de la réalisation de ce besoin ? (valeur métier).

La description est un support pour les autres étapes. C’est pour cela qu’il faut éviter de :

  • Trop détailler la description;
  • Perdre la notion utilisateur dans la description.

Exemple : « Payer avec sa carte de crédit » n’est pas une bonne pratique.

  • Utiliser des acteurs génériques (« utilisateur »). Cela peut créer des ambiguïtés.

Exemple :
– En tant qu’utilisateur, je veux pouvoir me connecter au guichet afin d’accéder à mon compte.
– En tant que client, je veux pouvoir me connecter au guichet pour accéder à mon compte.

Dans ce cas précis, un utilisateur du guichet peut être un client de la banque comme un client d’une autre banque.

Communiquer en vue de l’amélioration d’une User Story
Apres la description, cette étape consiste à discuter avec les différents acteurs du projet dans le but de :

  • Comprendre, d’expliquer et de négocier avec le client pour une meilleure définition du besoin;
  • Estimer la User Story  et la subdiviser si nécessaire;
  • Compléter si nécessaire la description de la User Story par des exemples pour faciliter la compréhension.

Confirmer la User Story avec les critères d’acceptabilité
Lors des négociations autour d’une User Story, il faut également évoquer avec les stakeholders, les critères d’acceptabilité d’une User Story. Pour les définir, on peut aider le client à travers des questions comme : Comment ? Que faire si ? Quand ? etc.

Exemple : En tant que client, je veux pouvoir faire un retrait au guichet automatique dans le but d’éviter les fils dans les agences.

Pour obtenir un critère, on peut se poser la question :
– Que faire si je n’ai pas assez d’argent sur mon compte ?
– Quand est ce qu’il faut refuser le retrait d’argent ?

Rédiger de bonnes Users Stories, c’est aussi de bonnes pratiques en amont

Beaucoup d’équipes se jettent dans la rédaction des Users Stories sans vraiment penser à définir au préalable les rôles utilisateurs, ainsi que la vision globale du projet. Différentes techniques permettent de définir les utilisateurs d’un système. On peut citer :

  • Profil utilisateur : technique utilisée pour définir les responsabilités et les tâches;
  • Rôle utilisateur : décrit les contextes, les caractéristiques et les critères des rôles;
  • Persona : définit un utilisateur-type, une représentation fictive des utilisateurs cibles.

Identifier les utilisateurs-types au début du projet et les communiquer à tous les stakeholders
Dans le cadre de projets agiles, une combinaison des rôles utilisateurs et du Persona permet d’identifier les rôles existants et d’en faire des utilisateurs-types qui serviront de fil conducteur pour la rédaction des Users Stories.

Définir les Customer  journeys  pour avoir une vision globale du projet
Certes, il n’est pas toujours évident d’avoir une vision globale d’un projet mais une technique permet d’avoir un fil conducteur des valeurs métiers des utilisateurs : Customer journey. Cette technique sert à décrire le parcours utilisateur. Elle permet :

  • Une gestion efficace des utilisateurs;
  • Une meilleure priorisation des améliorations;
  • Une meilleure compréhension des processus par l’équipe.

Conclusion

En somme, les Users Stories sont une technique d’expression des besoins qui exige une simplicité tout en vehiculant une vision utilisateur. Bien les rédiger, c’est :

  • Clarifier en amont la vision du projet ainsi que les rôles utilisateurs;
  • Impliquer le client dans la phase de rédaction et respecter les caractéristiques INVEST.

 

Share
Fiacre KINMAGBAHOHOUE
Fiacre KINMAGBAHOHOUE

69049

Comments

  1. Quentin Vignier Quentin Vignier Says: February 13, 2014 at 11:02 am

    Un très bon article qui intervient avec un timing parfait puisque je tente justement de faire passer mon client à la rédaction de User Stories et qu’il me fallait un support lui présenter le concept et la méthodologie de rédaction.

    • Le cardinal Says: March 27, 2016 at 8:28 am

      Bonjour excellent article très concis. Avez vous une version de cet article traduite en anglais ?

    • On se retrouve dans le meme cas ou je veux epargner mon client de la redaction des user stories. on discute en fond de son besoin et des differentes contrainte et moi je fais le reste.

  2. Regis MAHOUKOU Says: April 7, 2016 at 2:33 pm

    Bonjour,
    Par expérience, je vois souvent que la dernière partie de la user story, le fameux “Afin de…”, est oubliée. Ce que je préconise en tant que coach agile est de commencer par le “Afin de…” (start by WHY) ce qui donne :
    “Afin de…, en tant que…,je veux…”.
    Une autre variante, plus fluide en sonorité, donne ceci :
    “Dans le but…, en tant…, je veux”.

    • François Ronnoirs Says: September 14, 2016 at 3:43 am

      Je ne suis pas forcément d’accord. Le fait de modifier la phrase comme vous le faites ne sonne même pas correctement en bon Français. Exemple: “Afin de retirer de l’argent, en tant que client, j’ai besoin d’une carte de crédit” sonne et se lit beaucoup moins bien que “En tant que client, j’ai besoin d’une carte de crédit afin de retirer de l’argent”

  3. sur quel logiciel je peut travailler avec user story ??? j’attend une réponse svp

  4. Raphaël BOESCH Says: July 7, 2017 at 2:05 pm

    Dans Jira, il y a entre autres les champs “Summary” et “Description”. Mais dans cet article, il me semble que vous ne parliez que de la “Description”.
    Quel format utilisez-vous pour le “Summary” qui doit tenir en quelques mots ?

    • Sophie Page Sophie Page Says: January 24, 2018 at 5:19 am

      Bonjour Raphaël, pour le Summary, je dirais qu’il y a 2 pratiques tout aussi valables l’une que l’autre. Certains utilisent le format …… dans le Summary et utilisent la description plus pour les Acceptance criteria et autres détails. D’autres utilisent une formulation raccourcie qui permet quand même de comprendre rapidement quel est le but de la story et de ne pas avoir de doublons. Mais il n’y a pas de format spécifique. Pour la story donnée en exemple dans cet article: “En tant que client, je veux pouvoir faire un retrait au guichet automatique dans le but d’éviter les files dans les agences.”, je mettrais le summary “Retrait au guichet automatique”. S’il y a plusieurs stories concernant le retrait au guichet automatique, je serais un peu plus spécifique. Par exemple il pourrait y avoir une story qui gère le cas du refus de la transaction et une qui gère le cas où la transaction est acceptée. J’aurais alors les summary “Retrait au guichet accepté” et “Retrait au guichet refusé” par exemple.
      En tout état de cause, restez simple et pensez pratique. Il faut que l’on sache rapidement de quoi parle les stories en ne voyant que leurs summary dans une liste. Cela facilite beaucoup la gestion du backlog. Vous ne voulez pas avoir à ouvrir la story à chaque fois lorsque vous priorisez le backlog par exemple.
      J’espère avoir répondu à votre question.

  5. Bonjour, J’ai une question, du coup la solution technique ne doit elle pas s’afficher dans la description (La notion du WHAT et du HOW ?) si le HOW ne fait pas parti de la US, il est mentionné ou ?
    La complexité de la carte ne prend t-elle pas justement en compte la complexité technique ?

    Merci

    • Sophie Page Sophie Page Says: January 24, 2018 at 5:34 am

      Bonjour Soraya et merci pour votre question.
      La solution technique choisie ne fait pas partie de la user story car il ne faut pas limiter le choix des développeurs. Ils doivent pouvoir explorer différentes possibilités d’implémentation au moment du sprint planning ou en délivrant la user story. La solution technique retenue est documentée par le code en lui-même. Il peut éventuellement y avoir un commentaire sur la user story pour indiquer pourquoi on a fait un choix technique plutôt qu’un autre au moment de son développement.
      En terme d’estimation de la complexité, durant le sprint planning, les discussions autour de la solution technique vont émerger d’elles-mêmes. Il est possible de commenter la user story à ce moment là si le choix, par les développeurs, d’une solution plutôt qu’une autre à un gros impact.

  6. Yvan Carel Says: May 4, 2018 at 4:37 pm

    Bonjour,
    Excellent article. Cependant, j’ai une préoccupation: Dans le cas où les fonctionnalités de l’application ou du micro-service ne seront pas utilisées par une personne mais par d’autres micro-services, comment rédiger le User Story? merci

    • Estelle Says: May 22, 2018 at 5:51 pm

      Bonjour Yvan et merci pour votre question.

      D’un point de vue plutôt technique une application est souvent vue comme un empilement de composants un peu comme un hamburger ou un wedding cake: il y a l’interface graphique pour communiquer avec l’utilisateur, le service (micro ou non) qui sollicite d’autres services, la couche de logique métier et finalement la couche d’accès aux données. Et si en terme d’architecture d’application la séparation des responsabilités sur différents composants est une bonne pratique en revanche écrire des “user” stories pour chacun de ces composants ne l’est pas car elle viole au moins deux caractéristiques essentielles d’une user story « Valorisable » (apporte de la Valeur à l’utilisateur final) et « Testable » (par l’utilisateur final).

      Pour créer une véritable user story un changement radical de perspective doit être opéré. L’application doit être pensée du point de vue d’un utilisateur ne connaissant rien (oui vraiment rien !) à la technique, c’est à dire en termes de comportements ou d’informations qui lui apportent à lui une vraie valeur.

      Parfois, pour effectuer et pérenniser ce changement radical de perspective et pour tirer au mieux partie de la mise en oeuvre de pratiques agiles telle que la description du besoin sous forme de user stories, il est utile de revoir l’organisation des équipes projets pour basculer d’équipes dites « component teams » alignées sur l’architecture technique (par exemple les équipes front et back) vers des équipes projets appelées « feature teams » alignées sur des thématiques fonctionnelles.

Leave a Reply

Your email address will not be published. Required fields are marked *