User Stories en action : Exemples et Cas Pratiques

Définition : Récit Utilisateur (user story). « Un récit utilisateur est une brève description d’un résultat pour un utilisateur spécifique, conduisant à une conversation pour obtenir plus de précisions ». Source : PMBOK® (Project Management Body of Knowledge).

Quiz : Quels sont les mots clés les plus importants de cette définition ?

A/ Description et résultat

B/ Résultat et utilisateur spécifique

C/ Résultat et conversation

D/ Description et précision 

Corrigé du quiz en bas de cet article [1]  

Introduction 

Dans le monde effervescent du développement logiciel, il existe une pratique qui a révolutionné la façon dont nous concevons et développons les produits mais qui reste abstraite : les User Stories (en français « récit utilisateur »). Ces petites perles de sagesse, nées de l’approche agile, sont devenues le langage universel entre les commanditaires [2], transformant les désirs des utilisateurs en fonctionnalités tangibles et les concepteurs de logiciels.

Mais qu’est-ce qu’une User Story ? Comment sont-elles nées ? Pourquoi sont-elles si importantes ? Comment les utiliser efficacement ? Et qu’est-ce qui fait une bonne User Story ? Dans cet article, nous allons explorer ces questions et plonger dans le monde fascinant des User Stories. Alors, asseyez-vous confortablement, détendez-vous et préparez-vous à entrer dans le royaume où les utilisateurs sont rois et les concepteurs leurs fidèles serviteurs. 🙂

L’histoire des User Stories

Schéma n°1 : Photo de Rachel Davis, de la société « Connextra » montrant une « User Story » lors des XPDay le 15 décembre 2001

D’ailleurs, pour la petite histoire, à l’origine, ils n’utilisaient que l’expression « stories » pour pouvoir contextualiser les demandes et ce ne quelques années après, notamment via la conférence de Londres de la compagnie Connextra exposées un peu plus bas dans cet article, que l’expression « user story » s’est popularisée. L’idée était de pouvoir mettre l’accent sur la satisfaction des utilisateurs finaux des logiciels en un minimum de temps et non sur de la conformité à des spécifications parfois contradictoires d’un cahier des charges de plusieurs milliers de pages. Vous l’aurez compris, l’idée était simple : au lieu de se perdre dans le jargon technique et les détails de mise en œuvre, il fallait se concentrer sur ce que l’utilisateur final voulait vraiment. Eh bien voilà, c’est ainsi que les « user stories » sont nées ! Elles sont devenues une partie intégrante de nombreuses approches de développement agile, car elles aident à garder l’accent sur les besoins et les objectifs de l’utilisateur final. Elles sont conçues pour encourager l’équipe de développement à voir les fonctionnalités du point de vue de l’utilisateur, un peu comme si vous regardiez la face « avant de la montre » (dimension fonctionnelle) et non pas la face « arrière de la montre » (dimension technique).

Qu’est-ce qu’une bonne User Story ?

Le principe d’écriture d’une user story n’est pas d’être exhaustif mais de permettre une « discussion » avec l’équipe de développement. Souvenez-vous de la définition du PMI® exposées en début d’article « Un récit utilisateur est une brève description d’un résultat pour un utilisateur spécifique, conduisant à une conversation pour obtenir plus de précisions ». Source : PMBOK® (Project Management Body of Knowledge). Les mots clés le plus important de cette définition sont « conversation » et « résultat » (cf. corrigé du quiz à la fin de cet article).

• Une conversation: Une conversation entre l’auteur de la User Story et le concepteur du logiciel est indispensable puisque les mots n’arrivent pas toujours à traduire ce qu’on pense ou ce qu’on ressent.

• Un résultat (outcome) : Les plus expérimentés d’entre vous me diront qu’en fait une User Story c’est simple : c’est l’équivalent d’une spécification fonctionnelle ! Oui mais non ! Une « user story » offre toujours plus des marges de liberté au développeur informatique que la spécification fonctionnelle (exprimée historiquement au travers d’une matrice de traçabilité des exigences). C’est ce qu’on appelle la logique d’outputs (donnée de sortie) vs la logique d’outcomes (résultat visé). Je vous explique :

• • • • Les « outputs » se réfèrent aux produits, services ou fonctions spécifiques qui résultent directement d’un objectif ou d’un processus. Ils sont généralement mesurables et tangibles. C’est une action spécifique qui a un résultat direct et mesurable. Exemple : je veux installer un bouton de connexion « Paypal » pour pouvoir effectuer les paiements en ligne. Mais j’aurais très bien pu choisir d’autres solutions de paiement, c’est-à-dire d’autres « outputs », par exemple : « Mastercard », « Stripe », « American Express », etc.    

• • • • Les « outcomes » en revanche, se réfèrent aux objectifs ou aux résultats finaux que l’on souhaite atteindre. Ils ne sont pas nécessairement liés à un output spécifique, mais peuvent être atteints par différents outputs. Exemple :  je veux installer un système de paiement pour pouvoir effectuer des paiements en ligne.    

NB : Si l’output est clair, il n’est pas nécessaire de formaliser un outcome ; on peut rédiger directement un output. La « user story » est généralement une description simple de quelque chose qu’un utilisateur veut faire sur un produit ou service. Elle est rédigée par un Product Owner mais elle peut aussi être rédigée par des membres de l’équipe ou des parties prenantes principale. Le product Owner en reste toutefois « redevable ». 

Stop ! Ne cherchez pas à écrire la User Story parfaite, elle n’existe pas !!!

Lors des discussions avec les clients, il est courant de se concentrer sur la rédaction parfaite de leur demande, afin de ne rien oublier et d’être conforme. Oui mais non ! Ce raisonnement est voué à l’échec. Pourquoi ? Parce qu’il est impossible de transcrire par écrit une sensation, une émotion ou un sentiment. L’écriture est limitée par notre pensée. La user story ne vise pas à tout retranscrire, mais plutôt à favoriser une conversation dynamique (cf. la définition citée en début d’article).

Au-delà des apparences : explorez les intrications invisibles de vos user stories  

Vous allez me dire, pourtant c’est simple lorsqu’on écrit « enlève le chat noir et met en un blanc », il n’y a pas 1000 interprétations à avoir, le client veut tout simplement supprimer le chat noir de la photo car il paraît que cela porte malheur ! Votre réponse aurait-elle été la même si je vous disais que la demande a été rédigée par un Anglais et traduite par un logiciel de traduction en français ? Pour rappel, « chat », signifie en Anglais : « discussion en ligne ». Ainsi, il y aurait 2 traductions possibles.

• Soit (traduction littérale) : “removes the black cat and puts in a white one” (enlève le chat noir et met en un blanc)
• Soit (interprétation correcte en anglais) : “removes the black chat space and turns it into a white one”  (enlève l’espace de discussion noir et met en un blanc à la place)

Dans le monde du « projet », on doit toujours partir du principe que la demande du client est « complexe ».  La complexité est d’ailleurs l’un des principes du PMBOK® (cf. 9ème principe du guide PMBOK® intitulé : « Se frayer un chemin dans la complexité« ).

Alors pourquoi utiliser des user stories et pas autre chose ? Eh bien c’est très simple, la force des user stories réside dans leur capacité à insuffler de la nuance, du contexte et de l’empathie face aux demandes froides de nos chers clients, traditionnellement exprimées par le biais d’exigences austères. La user story a le mérite d’apporter un « discours narratif » pour accompagner la demande. 

Extrait du film : la vérité si je mens 2

Les précieux conseils de Bill Wake : 

Bill Wake disait d’une User Story qu’elle doit être INVEST c’est-à-dire indépendante, négociable, valable (« Valuable » en anglais), estimable, petite (Small) et testable.

• Indépendante car la « user story » doit être autonome et ne pas dépendre d’autres « user stories ». Lorsque c’est le cas, on doit pouvoir facilement la tracer dans une démarche scénaristique globale différente (voir aussi la technique du story mapping).
• Négociable : La « user story » n’est pas un contrat ; les détails peuvent être modifiés et négociés par l’équipe de développement. D’ailleurs, ce point est complexe car le client doit comprendre qu’il va devoir faire des compromis sur d’autres aspects comme les coûts, la qualité ou les délais (cf. l’interview de Jean-Yves Klein, intitulé : pourquoi l’agilité échoue encore ?)
• Valable (« Valuable » en anglais) : La « user story » doit apporter de la valeur à l’utilisateur final. C’est ce qu’on appelle la « valeur business » ou encore la « Business Value ».
• Estimable : L’équipe de développement doit être en mesure d’estimer le temps nécessaire pour développer la « user story » notamment en lui attribuant des points d’effort (Story Points) via la technique du « Poker Planning ».
• Petite (Small) : La « user story » doit être suffisamment petite pour être développée dans un sprint. Pour qu’on puisse toujours travailler sur des sprints apportant de la valeur à l’utilisateur final.
• Testable : Il doit être possible de vérifier que la « user story » a été mise en œuvre correctement. Par exemple, cet article de blog a d’abord été testé et relu dans un format « brouillon » avant d’être « publié » pour être mis à la disposition des lecteurs.

Les 4 familles de User Story :

Parfois, les parties prenantes ont du mal à percevoir « la valeur » du travail accompli par les équipes enfin de sprints. C’est la raison pour laquelle Philippe Kruchten (un ingénieur logiciel canadien et professeur de génie logiciel à l’université de la Colombie Britannique) a proposé un modèle de classification des User Story en 4 grandes familles.

1. La User Story « Valeur » : c’est celle qui va porter le plus « d’utilité » possible en un minimum de temps aux parties prenantes. C’est par exemple : la User Story permettant d’implémenter une solution paiement (Paypal, Visa, Mastercard, etc.) ou encore la User Story permettant de se connecter à son compte de façon sécurisée (double authentification par SMS, bouton de connexion, etc.). Cette User Story est visible par les parties prenantes.

2. La User Story « Débogage » : C’est celle qui va déboguer les fonctionnalités validées précédemment mais qui ont rencontré des « bugs » à posteriori. Par exemple, on constate qu’il y a une faille de sécurité qui a laissé un inconnu se connecter à un site web sans y avoir été autorisé. On observe un problème d’affichage entre la version PC et Mobile (responsive), etc. Cette User Story est également visible par les parties prenantes (l’application était en panne et maintenant elle refonctionne).

3. La User Story « Travail invisible » : il s’agit ici d’un travail invisible aux yeux des parties prenantes. Par exemple : faire un travail de recherche pour pouvoir monter en compétences sur un code informatique très spécifique, analyser des données sans grande valeur pour les parties prenantes comme les réseaux de neurones informatiques exploités par ChatGPT n’apportent par une grande valeur pour les parties prenantes mais sont indispensables pour les développeurs informatiques. Cette User Story est, comme son nom l’indique, invisible aux parties prenantes, il faut donc faire preuve de pédagogie pour pouvoir expliquer leur utilité aux parties prenantes (cf. effet tunnel).

4. La User Story « Dette technique » : Celle-ci est difficile à expliquer aux parties prenantes, car ils ont du mal à se les représenter mentalement. Généralement, les dettes arrivent lorsqu’on veut « coder vite ». La tentation, sur ce type de user story, est de ne pas en tenir compte, à l’exemple des pneus de voitures usagés. les pneus usés peuvent fonctionner pendant un certain temps, mais peuvent, à terme réduire l’adhérence de la voiture à la route, ce qui peut augmenter les risques de surcoûts : changement de pneus, changement de jantes et cela peut même entraîner un accident de la route dont les coûts pourraient être décuplés par 10, 20 ou 30 (sans parler des potentielles pertes de vies humaines !). Eh bien de la même façon, la dette technique engendre des petits problèmes dans le code informatique qui, s’ils ne sont pas résolus, peuvent causer des problèmes beaucoup plus importants à l’avenir. Cette famille de User Story est également invisible aux parties prenantes, il faut donc savoir faire preuve de pédagogie pour l’expliquer sereinement aux parties prenantes.

Schéma n° 2 : La toute première User Story

présentée par la société « Connextra »

Le format des « User Stories » a été popularisé par Rachel Davis et Tim Mackinnon de la société « Connextra » (avec la Connextra Story Card), suite à une conférence intitulée « Tuning XP » à Londres le 15 décembre 2001. Comme vous le voyez sur l’image (cf. schéma n°2), la fiche initiale comportait déjà les informations les plus importantes. A savoir :  

1. Un titre court de la User Story: (il doit être facilement interprétable à la manière d’un panneau de signalisation « stop !»)
2. Perspective : à l’époque, ils appelaient « perspective » ce qui correspond aujourd’hui au « rôle » de l’utilisateur concerné par la « user story ». (L’équivalent du « en tant que » de la technique du scénarii d’utilisation).
3. Reserved for priority : indiquer le niveau de priorité de la Business Value (valeur business) de la User story (vous pouvez utiliser ici des gommettes de couleur) pour signifier les degrés de priorité : Vert: peu prioritaire, Orange : modérément prioritaire, Rouge : hautement prioritaire.
4. Requirements : à l’époque, ils appelaient « Requirements» (exigences) ce qui correspond aujourd’hui au « quoi » de la « user story » (L’équivalent du « je veux » de la technique du scénarii d’utilisation).   
5. Reason : à l’époque, ils appelaient « Reason » (justification) ce qui correspond aujourd’hui au « pourquoi » de la « user story » (l’équivalent du « pour » de la technique du scénarii d’utilisation).
6. Author: Le nom de l’auteur(rice) est important car il permet de « tracer » les parties prenantes du projet et savoir « qui » a demandé ou rédigé ladite User Story. L’idée est simple : pouvoir retrouver facilement celui/celle qui est à l’initiative de la User Story et clarifier sa demande le cas échéant (cela paraît tellement évident mais dans un projet avec pléthore de parties prenantes, c’est indispensable ! :)).
7. Date: Pour savoir quand a été demandé ou rédigé ladite User Story.
8. Reserved for estimate: Pour savoir quel point d’effort représente la User Story. Cette estimation est généralement faite lors de la cérémonie du Sprint Planning avec la technique du « Poker Planning ».

Les 5,5 bonnes pratiques pour rédiger une bonne User Story

Il existe plusieurs étapes pour rédiger une « user story » efficace. Cela commence par raconter des histoires, ne pas se soucier trop tôt des détails, et se concentrer sur les résultats plutôt que sur les solutions. Voici les étapes détaillées :

Étape 1 : Soyez prêt à raconter des histoires !

Comme nous l’avons vu précédemment on ne peut pas tout dire par écrit. Ce qui compte c’est donc le « discours narratif » qui l’accompagne. Ce discours permettra à celui qui l’écoute de mieux « comprendre » ce que vous voulez proposer aux utilisateurs finaux. C’est la raison pour laquelle on a utilisé l’expression « story » (histoire).  

Imaginons l’exemple suivant. Mettez-vous dans la peau de Reid Hoffman, le fondateur de l’application LinkedIn. Supposons que vous souhaitiez créer l’application LinkedIn pour la toute première fois de votre vie (LinkedIn a été créée en 2002). Au lieu de simplement écrire « En tant qu’utilisateur, je veux pouvoir me connecter à d’autres professionnels », le concepteur de la US doit être prêt à raconter une histoire qui interviendra lors de la discussion orale qui s’en suivra et l’expert technique devra être prêt à vous poser un maximum de question : « Imaginez Sarah, une ingénieure superstar, qui a passé une décennie à construire des ponts. Maintenant, elle veut construire des relations. Elle veut se connecter à d’autres professionnels sur LinkedIn, pas seulement pour échanger avec ses collègues, elle veut discuter avec d’autres ingénieurs d’autres entreprises et tout autre type de décisionnaires pour développer sa carrière.

Étape 2 : Soyez prêt à décrire un changement de comportement 

Imaginez Sarah en train de lire un livre captivant sur les tartes aux citrons meringuées. Elle tourne les pages, une après l’autre, chaque page révélant un nouveau chapitre de l’histoire : là, on est sur un changement de « comportement » chaque fois que Sarah tourne la page. Eh bien pour la création de notre application « LinkedIn » on va faire la même chose, on va imaginer comment vont naviguer « les doigts » de Sarah et où ses « yeux » vont regarder. Dès qu’il y a un changement de comportement (de gestuelle ou de regard donc), on aura une user story potentielle. On est dans le « quoi » de la user story décrit plus haut.   

Exemple : « Après avoir créé son profil, Sarah veut pouvoir se connecter à d’autres professionnels dans son domaine. Elle s’attend à ce que LinkedIn lui permette d’envoyer des invitations de connexion. »

Étape 2,5 : Soyez prêt à décrire un changement du système :

Pour maximiser vos chances d’avoir un logiciel opérationnel. Vous allez également observer les changements de système. Si on reste sur notre application Linkedin, imaginons à présent que chaque page du site est un système différent du site. Chaque fois que Sarah clique sur une nouvelle fonctionnalité, une page par exemple, elle provoque un « changement de système ». Une autre façon de voir ce changement de système correspond à la flèche rotative qui apparaît à gauche de la barre d’URL lorsque vous chargez une nouvelle page (cf. schéma n°3 ci-dessous). Chaque fois que cette flèche tourne, c’est le signe qu’un « changement de système » se produit. On est toujours dans le « quoi » de la user story. Attention sur ce point à ne pas tomber dans les travers des cas d’utilisation (diagramme UML). D’où le demi-point pour cette étape.     

Si on reste sur le bouton de « connexion » de l’application LinkedIn, vous pourriez très bien écrire ceci : « Pour permettre à Sarah de se connecter à d’autres professionnels inscrits sur LinkedIn (fonctionnalité n°1), Sarah doit pouvoir visualiser les photos des professionnels de son domaine d’expertise (fonctionnalité n°2) et avoir la possibilité d’envoyer des invitations de connexion en appuyant sur un bouton de connexion facilement identifiable (fonctionnalité n°3). »

Schéma n°3 : Illustration d’un changement de « système »

Étape 3,5 : Utilisez des Post-it® !

Imaginez une pile de Post-it® multicolores, un tableau blanc (le product backlog) et une salle de réunion. Chaque Post-it® est une user story, une petite fenêtre sur le monde de votre application, LinkedIn dans notre cas. NB : Il existe une technique très réputée pour structurer les user stories, appelée ‘story mapping’. Toutefois, étant donné que sa richesse mérite une exploration distincte, il m’a paru plus judicieux d’aborder cette technique dans un autre article que nous aborderons dans un futur proche pour ne pas détourner notre attention du sujet actuel.

Vous prenez un Post-it® bleu et vous écrivez :

• Création de profil :
  • En tant qu’utilisateur Linkedin de type 1 (utilisateur de type 1 = demandeur d’emploi) ;
  • Je veux pouvoir créer un profil mettant en avant mes compétences, mon expérience, mes idées et mes réalisations professionnelles ;
  • Pour partager mes compétences professionnelles.

C’est votre première user story. Vous l’accrochez sur votre tableau blanc, vous venez d’avoir un premier coup de pinceau sur votre toile.

Un Post-it® rose suit :

• Ajout de photo sur Profil :
  • En tant qu’utilisateur LinkedIn de type 2 (utilisateur de type 2 = décisionnaire d’entreprise) ;
  • Je veux pouvoir ajouter une photo de profil [3] ;
  • Pour créer une connexion émotionnelle avec les utilisateurs de Linkedin favorisant la mémorisation du profil, l’aperçu de la personnalité.

Un par un, vous créez des user stories, chaque Post-it® ajoutant une nouvelle touche de couleur à votre board par thématique :

• Mises à jour de statut :
  1. • En tant qu’utilisateur Linkedin de type 3 (utilisateur de type 1 = demandeur d’emploi),
     • Je veux pouvoir publier des mises à jour de statut
     • Afin de partager mon actualité avec mon réseau professionnel.

• Partage d’articles :
  1. En tant qu’utilisateur de LinkedIn de type n°2 (utilisateur de type 2 = décisionnaire d’entreprise)
  2. Je veux pouvoir partager des informations sur mon entreprise
  3. Afin d’augmenter la notoriété de mon entreprise et la mienne par la même occasion

Etc.

Et voilà, votre tableau est maintenant une mosaïque de Post-it®, chaque couleur représentant une fonctionnalité différente de LinkedIn. C’est un kaléidoscope de fonctionnalités ! 🙂 Et tout cela a commencé avec de simples Post-it® ! Magique non ?

Étape 4,5 : Créez des critères d’acceptation au dos des Post-it® des user story.

La création de critères d’acceptation « au dos » des user stories est une pratique essentielle en développement Agile. Ces critères définissent les conditions mesurables qui doivent être remplies pour qu’une user story soit considérée comme acceptable. Ils servent de guide pour les développeurs lors de la mise en œuvre de la fonctionnalité, mais également pour les testeurs lors de la vérification de son bon fonctionnement.

Prenons la User Story suivante :

• En tant qu’utilisateur de LinkedIn de type 1 (utilisateur de type 1 = demandeur d’emploi) ;
• Je veux postuler à des offres d’emploi directement sur LinkedIn
• Afin de simplifier mon processus de recherche d’emploi.

Attention à ne pas confondre D.O.D

et Critères d’acceptation

Étape 5.5 : Utilisez votre caméra !

Sur certaines user stories stratégiques ou difficiles à verbaliser, Jeff Patton (le fondateur de la technique du story mapping) nous recommande d’utiliser une caméra pour filmer l’échange entre celui qui a du mal à rédiger la user story (généralement un expert métier venant du commerce, du marketing, des achats, etc.) et un expert technique (généralement un développeur web ou un membre de l’équipe de développement). Je trouve que c’est une excellente idée ! Ensuite, il vous suffira de créer un QR Code de l’échange et de le positionner sur le Post-it®. L’idée étant que celui qui visionne cet échange pour la première fois puisse augmenter ses chances de « comprendre » les subtilités et les nuances dont on parlait précédemment (souvenez-vous l’écrit ne peut pas TOUT retranscrire !).

Conclusion

Ah, les « user stories », ces joyaux étincelants dans le trésor des équipes agiles, ces pépites d’or qui guident le travail de ces artisans de l’agilité. Comme un phare dans la brume, elles éclairent le chemin vers la satisfaction des besoins des utilisateurs !

Telles des boîtes de chocolats, elles nous rappellent qu’il vaut mieux « discuter » avant de croquer dedans, car on ne sait jamais si on va tomber sur une noisette croquante ou une cerise imprévisible ! 🙂

Leur sagesse légendaire, nous rappelle qu’il vaut mieux admirer le panorama des résultats (outcomes) plutôt que de se perdre dans la jungle des données de sortie (outputs).

En effet, les « user stories » sont comme les guimauves autour des feux de camps, elles favorisent la conversation, invitent à la collaboration et la communication au sein des équipes, unissant les individualités en une seule voix : la voix de l’utilisateur final.

________________________________

__________________________________

Sources et références :

• Fifty Quick Ideas to improve your user stories, Gojko Adzic and David Evans (version anglaise) 
• Le story Mapping, Jeff Patton    

Notes de bas de page : 

[1] Corrigé du quiz : Option C. Effectivement, la User Story « magique » n’existe pas. Lorsqu’elle est rédigée, elle doit permettre de démarrer une discussion pour pouvoir comprendre les subtilités et les nuances exigées par l’auteur initial de la demande.  

[2] Les commanditaires des logiciels sont généralement ceux qu’on appelle les gens du métiers (les responsables marketing, commerce, etc.) et les concepteurs de logiciels sont généralement ceux qu’on appelle les gens de la technique (développeurs informatiques, testeurs, designers, etc.).

[3] comme je vous le disais si l’output est clair, il n’est pas nécessaire de formaliser un outcome ; on proposer directement un output.