Une bonne user story pour une bonne gestion de projet Kanban, qui respecte les exigences du Lean et la philosophie Agile… on en rêve tous ! Mais vous a-t-on perdu ? Si ce n’est pas le cas, vous souhaitez peut-être en apprendre plus sur la user story pour perfectionner vos pratiques.
Ou alors la phrase ci-dessous n’a aucun sens pour vous… et on vous explique. Nous sommes dans le vaste monde des méthodes de travail et des techniques de gestion de projet. Dans cet univers parallèle, les méthodes Lean et Kanban sont apparues pour améliorer la productivité, tout comme la philosophie AGILE née en 2001, qui a inspiré de nombreuses pratiques, dont la méthode Scrum.
Mais toutes ces techniques d’amélioration de la production ou de la gestion de projet ne serviraient à rien si à la base n’existaient… le client et ses besoins. Là est le nerf de la guerre : la nécessité de satisfaire le client (ou l’utilisateur) et de répondre à ses exigences.
Pour cela, rien ne vaut une user story, ou “récit utilisateur” en français : il s’agit tout simplement de partir du point de vue de l’utilisateur final pour comprendre comment améliorer notre produit, logiciel ou service, et donc monter en qualité. Suivez le guide !
Table des matières
Qu’est-ce qu’une user story ?
Une user story ou “récit utilisateur” est une simple phrase, assez courte pour tenir sur un post-it, qui sert à exprimer un besoin de l’utilisateur en vue d’une amélioration d’un produit ou d’un logiciel.
Histoire et apparition des user stories
Bien que souvent associée aux outils Agile et Scrum, la user story a été créée par Kent Beck en 1990, au sein de sa méthode Extreme programming.
Mais comme celle-ci s’appuie sur la relation client, elle répond à l’un des quatre principes fondamentaux de la méthode Agile, à savoir “la collaboration avec le client est plus importante que la négociation des contrats”. Par cette proximité et ses atouts évidents, la user story fut donc adoptée dans les gestions de projet Agile et Scrum.
La user story est un outil de communication au sein d’une équipe collaborative dans un objectif d’amélioration d’un produit ou d’un service. On part du point de vue de l’utilisateur ou du client, dont on aura cerné les besoins ou compris un problème rencontré, et l’on rédige une courte phrase résumant ce besoin.
Ce “récit utilisateur” servira de guide et d’objectif clair pour toute une équipe, dans un processus d’amélioration d’une fonctionnalité.
Outil de communication donc, car la user story doit être compréhensible pour tout acteur, quel que soit son rôle (y compris pour l’utilisateur final). Pour éviter la confusion, il est également important que sa rédaction soit impeccable. N’hésitez pas à utiliser un correcteur de faute tel MerciApp pour éviter d’y laisser des coquilles.
Qui rédige les user stories ?
Au sein de la méthode Scrum, la définition d’une user story est le point de départ des cycles de travail appelés sprints. Mais c’est aussi l’aboutissement d’une longue recherche sur les besoins des utilisateurs.
C’est donc en priorité au Product Owner (PO) qu’incombe la responsabilité de rédiger des user stories fidèles à la réalité. Son rôle est en effet de comprendre les attentes des utilisateurs dans un objectif d’amélioration constante du produit. Il est une sorte de chargé de projet, mais côté client.
Remarque :
Si la rédaction des user stories est une part essentielle de son travail, le Product Owner peut être aidé dans cette tâche par d’autres membres de l’équipe, au sein d’un atelier collaboratif par exemple, ou après une enquête de satisfaction client menée par d’autres membres.
Le guide de la productivité en entreprise
Découvrez les 12 secrets de productivité des entreprises à succès : Téléchargez votre guide gratuit exclusif et transformez votre façon de travailler dès aujourd’hui !
De l’epic à la user story
La user story doit être simple et courte. Mais elle s’inscrit bien sûr dans une dimension plus large d’amélioration et de recherche de plus-value permanente. Ainsi, les user stories peuvent être associées à d’autres au sein d’un plus grand ensemble nommé epic.
Un epic, ou “épopée” en français (qui est une histoire plus vaste que le récit, comme quoi le monde des développeurs n’est qu’un monde de littéraires 2.0…), est donc une sorte de macro-user story dans laquelle chaque user story va jouer un rôle.
Pourquoi utiliser le récit utilisateur ?
Une bonne user story a de nombreux avantages. Tout d’abord, elle vous fait gagner en pertinence : grâce à une approche centrée utilisateur, elle permet le développement de fonctionnalités utiles voire nécessaires.
Aussi, elle permet une meilleure collaboration d’équipe et mène ainsi à davantage d’efficacité : compréhensible par tous, la user story permet de fixer un but clair et précis. Même en plein cœur du projet, absorbé dans sa tâche, on peut toujours y revenir. De plus, c’est à partir de la user story que l’on définit les backlogs, c’est-à-dire la liste des tâches à effectuer.
Enfin, à long terme, définir des user stories permet d’avoir une banque de données de fonctionnalités à améliorer, dans un but de créer de la plus-value constamment !
Comment rédiger une bonne user story ?
Voici le moment de se lancer : mais comment rédiger une user story efficace ? N’a pas l’art de la formule qui veut… Suivez les étapes pour une US (le petit nom de user story) performante !
Recueillir les avis de ses clients
Une user story prend le parti d’adopter le point de vue des utilisateurs afin d’améliorer un produit et ses fonctionnalités. Autant donc connaître ce point de vue. Là est le premier travail à long terme qui se trouve en amont d’une bonne user story : connaître les avis de ses clients.
Remarque :
Cet avis peut être exprimé ou non. Si le travail du Product Owner prend tout son intérêt ici (à savoir réfléchir à tout ce dont les utilisateurs pourraient avoir besoin), il peut se faire aider par d’autres équipes, notamment les chargés de clientèle.
Questionnaires de satisfaction, sondages, rencontres, études des retours clients et des avis internet : tout cela doit être passé au peigne fin.
Élaborer des personas
Suite à ce travail, il vous faudra élaborer des personas. Cela vous permettra de cibler votre clientèle, de cerner les différents types d’utilisateurs et donc les différents besoins. Votre backlog gagnera en pertinence.
Exemple :
Si vous êtes une banque et que vous cernez deux profils très différents dans votre clientèle, à savoir le cadre de 40 ans qui souhaite rentabiliser ses entrées d’argent et la jeune bachelière qui souhaite étudier et voyager à l’international, il y a fort à parier que leurs besoins ne seront pas les mêmes.
Définir des user stories propres à chaque persona est donc un travail à mener !
Rédiger une user story simple, courte, mais efficace
Pour rédiger des user stories efficacement, autant avoir une formulation toute faite qui nous aide à la trouver. Et cela tombe bien, elle existe. Une bonne user story répond en effet à l’équation : utilisateur / besoins / objectif.
C’est ainsi qu’on la retrouve souvent sous la forme “En tant que” / “j’ai besoin de” / “afin de”. En utilisant ce schéma, vous êtes sûr de rédiger une user story qui réponde à son objectif.
Exemple :
Si l’on reprend notre exemple bancaire, une piste pour la deuxième persona définie serait : “En tant que jeune étudiante à l’international, j’ai besoin d’un taux de change intéressant afin de mieux gérer mes dépenses.”
Pour un modèle davantage axé sur les fonctionnalités d’une application : “En tant que cadre dynamique, j’ai besoin d’un accès rapide aux cours de la Bourse afin d’optimiser mes placements.”
Valider une user story
Vous avez rédigé votre user story, parfait ! Mais à présent, comment savoir si celle-ci apportera une véritable valeur ajoutée ? En la testant, tout simplement. Et pour cela, rien ne vaut la méthode INVEST.
INVEST est un acronyme qui vous permet de vous rappeler des critères à surveiller, en anglais dans le texte :
- Independant : chaque user story doit être indépendante, afin que l’on puisse facilement la mettre en place et l’évaluer ;
- Negociable : avant d’être utilisée pour le lancement d’un sprint, la user story doit pouvoir être discutée par chaque partie prenante et notamment l’équipe de développement ;
- Valuable : une user story apporte bien sûr de la valeur ;
- Estimable : on doit pouvoir estimer la complexité d’une user story, de façon comptable (par exemple avec des story points) ;
- Small : concision et simplicité sont les maîtres-mots d’une user story de qualité ;
- Testable : une user story doit permettre d’élaborer des critères afin de pouvoir tester sa réussite (ou son échec).
À la fin de chaque phase de rédaction de vos user stories, passez en revue chaque US grâce à cet acronyme facilement mémorisable : vous assurez ainsi un “contrôle qualité” !
Définir les critères d’acceptation pour évaluer la user story
Définir les critères d’acceptation, c’est vérifier que la user story répond bien à ses objectifs. Il s’agit d’un moment de test, traditionnellement opéré par l’équipe de développement et appelé dans la méthode Agile le backlog grooming.
Pour opérer ce test, on reprend les critères décidés à l’avance et on les met en action sous forme de scénario. Pour vérifier la user story “En tant que cadre dynamique, j’ai besoin d’un accès rapide aux cours de la Bourse afin d’optimiser mes placements.”, on va par exemple étudier plusieurs cas, grâce à la formulation “Étant donné que / Lorsque / Alors”.
Exemple :
“Étant donné que je suis connecté sur mon application bancaire, lorsque je suis sur la page d’accueil, alors j’ai un visuel qui me donne en direct les cours de la Bourse.”
“Étant donné que les cours subissent un fort changement, lorsque je ne suis pas connecté à mon application, alors je reçois une notification.”
Ces deux phrases (on en détermine classiquement entre trois et cinq) rédigées à l’avance permettent de définir le résultat visé par une user story et de vérifier s’il a bien été atteint à la fin du sprint. Et pour définir vos scénarios utilisateurs, le planning poker est l’outil parfait !
Exemples de user stories
Voici deux exemples d’autres user stories pour finir d’illustrer notre propos.
Exemple :
Prenons l’exemple d’un Product Owner d’une application de sport souhaitant une mise à jour pour répondre à différents besoins clients.
Selon le persona d’une jeune femme trentenaire souhaitant faire du sport pour se défouler après sa journée au bureau, il aura défini la user story suivante :
“En tant que jeune active sédentaire, j’ai besoin de partager mes séances de sport afin d’optimiser mon plaisir lors de ma pratique.”
Selon le persona d’un homme de cinquante ans souhaitant perdre du poids, il aura défini la user story suivante :
“En tant que personne devant perdre du poids, mais pas réellement sportif, j’ai besoin d’être motivé et encouragé dans mes efforts, afin de ne pas abandonner ma pratique sportive.”
Sur quelles fonctionnalités l’équipe de développement va-t-elle devoir travailler ? On vous laisse avec cette énigme : bonne réflexion !
Aidez vos amis à parfaire leur français
Partagez-leur cette page
