

Scrum board, burnup chart, mood board, logiciels de gestion de projet... découvrez les principaux outils scrum pour gérer vos projets en toute agilité.
Le média de ceux qui réinventent l'entreprise
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 :
💡 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 :
À 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 :
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 :
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 :
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 :
💡 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 :
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 :
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 :
👉 La User Story peut être considérée comme DoR si elle :
👉 La User Story peut être considérée comme DoD lorsque :
Pour vous aider dans la rédaction de vos User Stories, voici un template à télécharger et à remplir :
Template User Story
TéléchargerEn 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 ?