6 étapes pour rédiger une user story et prioriser la roadmap en équipe

La User Story fait partie de la panoplie d’outils du Product Owner.

Bien que faisant partie des artefacts de la méthodologie Scrum, la User Story est en réalité issue de la méthode eXtreme programming. Elle permet d’assurer le bon développement des items du backlog d’un produit, qui répondent aux besoins exprimés des utilisateurs.

Découvrez la belle histoire de la User Story, pourquoi l’utiliser et quelles sont les différentes étapes à suivre pour bien la rédiger, l’estimer et la qualifier.

Dans le contexte de la gestion de projet agile et du développement de logiciels, la User Story est un outil qui permet d’exprimer une demande de l’utilisateur, de manière très simple et claire. C’est la·le Product Owner qui est chargé de la rédiger, aidé de son équipe.

Aussi appelée US, elle permet de transformer le besoin en une ou plusieurs fonctionnalités. Elle permet également de prioriser les items du backlog.

🇫🇷 En français, la traduction de User Story est « récit utilisateur ».

Nous avons relevé les trois avantages principaux à rédiger une User Story :

• Favoriser la satisfaction des besoins et attentes spécifiques des utilisateurs, concernant certaines fonctionnalités d’un logiciel ou d’une solution proposée.

• Faire comprendre aux lecteurs (et donc à l’équipe) de manière précise quel est l’avantage du besoin exprimé. Il est ainsi possible d’atteindre un degré plus élevé de sensibilisation au besoin, et permet à l’équipe de développement de réfléchir à comment le résoudre avec des fonctionnalités.

• L’équipe sera capable d’estimer sa complexité de réalisation pour prioriser les items du backlog à développer lors d’un sprint, et maîtriser la planification grâce à la bonne compréhension du besoin.

💡 Grâce à la User Story, toutes les parties prenantes ont une vision alignée du besoin, exprimé dans un langage compréhensible par tous.

Une Epic agile, ou épopée en français, est un ensemble de plusieurs User Stories, souvent regroupées par besoin fonctionnel.

Contrairement à une US qui doit être livrée en un sprint, l’Epic est généralement livrée sur différents sprints.

Cette étape préalable à la rédaction de la User Story est fondamentale pour la réussite du projet. Si la User Story a lieu d’être, c’est parce qu’il existe un besoin à la source.

La·le Product Owner peut recueillir le besoin de l’utilisateur de la manière qui lui convient le mieux, par exemple via :

• un formulaire,
• une réunion,
• un atelier, etc.

À partir des besoins recueillis, le PO va avec son équipe créer un story mapping, qui consiste à dérouler les grandes étapes du parcours utilisateur d’un point de vue fonctionnel. Cela permet de mieux les comprendre et de les prioriser de manière logique.

La·le Product Owner peut maintenant écrire et formaliser la User Story.

S’il n’existe pas une structure normée et figée pour construire sa User Story, il existe tout de même quelques impondérables.

En lisant la US, on doit comprendre tout de suite :

• qui exprime le besoin,
• quel est le besoin auquel il va falloir répondre,
• et quelle est la finalité, le but, le gain.

Le modèle le plus classique de User Story se formule de la manière suivante :

En tant que {persona}, je souhaite {besoin} afin de {objectif}.

Avec ces quelques mots, on doit rapidement comprendre la valeur ajoutée de la User Story.

Voici un exemple concret :

En tant que client, je souhaite accéder au suivi de ma commande afin de m’assurer d’être présent lors de la livraison à domicile.

💡 Pour des raisons de lisibilité, vous pouvez donner un titre plus court à votre User Story. Par exemple « Suivi commande client ».

Afin de s’assurer que la User Story sera efficace, le Product Owner utilise généralement la grille INVEST, qui comprend différents critères de qualité, auxquels doit répondre une bonne User Story.

Ainsi, elle·il vérifiera si la User Story est :

• Indépendante : elle n’a aucune dépendance vis-à-vis d’une autre user story du backlog.
• Négociable : elle doit pouvoir être modifiée et affinée au fil des échanges et des retours.
• Valorisable : elle doit apporter une valeur ajoutée à l’utilisateur pour avoir une raison d’exister.
• Estimable : pour faciliter la planification du projet, l’équipe de développement doit être en mesure d’en déduire une estimation de temps de réalisation à sa simple lecture.
• Small : c’est-à-dire réalisable en un sprint, sinon, on peut la découper en plusieurs user stories plus petites (tout en restant chacune valorisable). Plus la US est courte, plus elle sera rapide et simple à développer.
• Testable : elle doit pouvoir être testée selon des critères d’acceptation pour pouvoir être validée.

L’estimation de la User Story est indispensable pour que l’équipe puisse choisir les User Stories du backlog les plus prioritaires à réaliser.

Voici quelques bonnes raisons d’estimer une US :

• repérer si elle n’est pas réalisable en un sprint et doit donc être redécoupée,
• inciter l’équipe à se projeter de manière concrète dans la réalisation nécessitant de comprendre sincèrement le besoin à satisfaire,
• permet de gérer la planification du sprint en priorisant les éléments,
• donner de la visibilité sur ce que l’équipe s’engage à réaliser pendant le sprint.

On ne se base pas sur des unités de temps, mais sur des story points, qui correspondent à des points de complexité. Ils permettent de quantifier l’effort nécessaire à fournir pour la réalisation.

La séquence de Fibonacci, où chaque nombre est la somme des deux précédents, est souvent préférée au système linéaire pour la quantification, car elle présente l’avantage d’être précise pour les tâches légères, tout en gardant une échelle raisonnable pour les tâches plus lourdes (0,5 ; 1 ; 2 ; 5 ; 8 ; 13).

Voici les méthodes les plus couramment utilisées pour l’estimation :

• le planning poker (ou Scrum poker) utilise des cartes comprenant :
  • les nombres de Fibonacci,
  • une carte point d’interrogation ❓ si l’US n’est pas assez précise pour être estimée,
  • une carte signe infini ♾️  s’il faut qu’elle soit redécoupée,
  • et une carte pause café ☕  si besoin de faire une pause.
• le bucket system : similaire au planning poker, il utilise l’image de seaux dans lesquelles les User Stories seront triées en fonction de leur complexité.
• la taille de t-shirt : utiliser les tailles de t-shirt XS, S, M, L ou XL pour estimer la complexité plus grossièrement que le planning poker.

💡 La priorisation prend en compte également des questions de budget, de délai ou de périmètre.

Cette mission est réalisée conjointement avec l’équipe de développement, à l’occasion du backlog grooming (ou backlog refinement).

Les critères d’acceptance ou d’acceptation constituent un mode d’emploi qui permet de vérifier que l’implémentation de la User Story répond bien au besoin initial.

Grâce à ce référentiel commun, on peut valider le résultat sans équivoque.

Pour bien définir vos critères d’acceptation, assurez-vous qu’ils soient :

• réalisables,
• estimables,
• compris et acceptés par tous,
• rédigés en équipe, idéalement.

Ils peuvent être rédigés sous forme d’un scénario avec le célèbre langage Gherkin, en reprenant la description de la User Story.

Voici ce que cela donne en reprenant l’exemple précédent :

👉 Scénario : le client souhaite consulter l’état de sa commande.

Étant donné que j’ai réalisé une commande, je me rends dans mon espace client pour suivre son avancement.

Lorsque je clique sur le numéro de ma commande

Alors je peux voir l’état du traitement de ma commande, ainsi qu’une date de livraison estimée.

Vous pouvez lister tous les scénarii possibles.

👉 Scénario 2 : le client souhaite consulter l’état de sa commande depuis l’email de confirmation

Étant donné que j’ai réalisé une commande, je souhaite suivre son avancement

Lorsque je clique sur le lien dans mon email de confirmation

Alors je peux voir directement l’état du traitement de ma commande, ainsi qu’une date de livraison estimée.

👉 On peut aussi énoncer les critères de manière plus précise sous forme de liste :

1. Je me rends sur le site,
2. Je vais dans mon espace client,
3. Je clique sur « Mes commandes »,
4. Je clique sur le numéro commande dont je souhaite voir l’avancement,
5. Je suis redirigé vers un écran récapitulatif qui indique l’état de commande ainsi que la livraison. 

Pour qualifier l’état d’une User Story, l’équipe doit définir des critères précis qui permettent de dire que la User Story est :

• prête à être développée, dans ce cas on parle de DoR (definition of ready),
• ou terminée, on parle alors de DoD (definition of done).

👉 La User Story peut être considérée comme DoR si elle :

• comprend un certain nombre d’éléments déterminés au préalable par l’équipe (critères d’acceptantes, wireframes, etc.),
• a été relue par le Product Owner,
• a été relue par un membre de l’équipe de développement,
• a été validée par le donneur d’ordre.

👉 La User Story peut être considérée comme DoD lorsque :

• les tests techniques ont été réalisés et validés,
• les tests fonctionnels ont été réalisés et validés,
• et que la revue de code a été faite.

Pour vous aider dans la rédaction de vos User Stories, voici un template à télécharger et à remplir :

En agilité, et plus particulièrement dans la méthode Scrum, une communication régulière et fluide est bien souvent vectrice de succès d’un projet.

La User Story constitue avant tout un support de communication que l’équipe peut adapter en fonction des projets et des besoins spécifiques.

Et vous ? Utilisez vous la User Story dans vos projets ?