User stories : comment bien les rédiger ?

En tant que Product Owner, vous en avez sûrement fait l’un de vos principaux outils de travail au quotidien. Censées guider le développement en décrivant le besoin fonctionnel pour répondre à un problème utilisateur, les User Stories viennent garnir le backlog de tout bon produit.

Pour commencer, qu’est-ce qu’une User Story ?

Dans les méthodes agiles, une User Story (de son petit nom US) est une phrase simple, rédigée dans un langage courant, qui permet de décrire avec suffisamment de précision le contenu d'une fonctionnalité à développer.

Dans la méthode agile Scrum dont elle est issue, la User Story est censée illustrer un besoin fonctionnel exprimé par les types d’utilisateurs. Elle vise ainsi à assurer que l’on délivre bien de la valeur pour nos usagers.

Pour le Product Owner, l’intérêt de rédiger des User Stories est triple :

• elles permettent de coller au maximum au besoin et à la vision de l’utilisateur (car elles sont exprimées de manière simple, en langage courant) ;
• elles engendrent un gain de temps considérable pour les équipes de développement dans leur compréhension de la fonctionnalité à développer (toujours grâce à sa forme synthétique) ;
• elles permettent d’aligner la vision, et de confirmer la compréhension du métier, du Product Owner, des développeurs, du Scrum Master, des testeurs et de toute autre partie prenante pertinente en les rassemblant autour d’un langage commun.

La création d’une User Story est donc a priori très simple : en fonction des besoins des utilisateurs ou de la technique, le Product Owner rédige la tâche à accomplir et l’ajoute à son backlog. Quelques minutes de travail et le tour est joué ?

Si seulement…

De la tête au post-it : concevoir une bonne User Story

En réalité, rédiger une belle User Story nécessite :

• une très bonne connaissance des utilisateurs
• une parfaite compréhension des problématiques techniques qui y sont liées.

Avant d’être retranscrite et proposée au développeur, la problématique fonctionnelle que l’on souhaite aborder nécessite d’être défrichée.

La User Story, fruit d’un cycle itératif de conception

C’est au sein du cycle itératif qui précède le développement et qui a pour objectif d’accoucher du backlog produit, que naît la User Story. Si les User Stories sont le carburant du développement, celui-ci ne représente qu’une petite partie de leur vie. La conception qui le précède peut démarrer des semaines, voire des mois avant le sprint et se déroule également selon des itérations.

Loin d’être une réflexion initiale rédigée à la va-vite sur un bête post-it, la rédaction d’une User Story est plutôt le point final d’un long cycle de recherches, de réflexions, d’échanges et d’ateliers en équipes.

Partir du besoin utilisateur

Au commencement d’une Story fonctionnelle se trouve un besoin. Qu’il soit exprimé directement par l’utilisateur du produit ou remonté par les parties prenantes, et formulé de manière plus ou moins précise, il convient de l’explorer davantage pour être en capacité de le traduire par la suite en fonctionnalité.

Pour cela, le Product Owner dispose de nombreux outils de recherche utilisateur, comme par exemple les interviews, et peut également réaliser des ateliers avec les interlocuteurs métiers dans le but de monter en compétences sur le sujet fonctionnel et de creuser le besoin.

Une fois le besoin recueilli et précisé, le Product Owner va se réunir avec son équipe produit (ex : UX designer, architecte, lead développeur…) pour réfléchir à des pistes de résolutions de ce besoin en fonction des possibilités techniques.

Du problème à la solution fonctionnelle en passant par la conception visuelle

Une fois défrichés, les sujets passent sous la baguette magique du Product Designer (qui est responsable de l’expérience utilisateur) qui exprime les solutions possibles sous la forme de maquettes fonctionnelles. Dans l’idéal, ces dernières sont testées auprès d’un panel représentatif des types d’utilisateurs, afin d’améliorer les fonctionnalités désignées et d’identifier la solution répondant le mieux au besoin exprimé.

Une fois qu’il dispose de représentations visuelles du sujet fonctionnel et d’une bonne vision sur les problématiques techniques, le Product Owner et son équipe vont pouvoir découper le besoin en fonctionnalités facilement développables par l’équipe.

Pour cela, l’équipe peut réaliser un

. Cet atelier consiste en la définition des grandes étapes fonctionnelles du parcours utilisateur, les Epics, qui sont ensuite découpées en Stories exhaustives. Ainsi représentées, les Stories sont plus faciles à ordonner et à prioriser, et permettent de créer un parcours logique et débarrassé de son superflu.

En fonction des délais, du budget ou du périmètre à couvrir, nombre d’idées prédestinées à devenir des User Stories vont être dépriorisées voire abandonnées.

Concevoir des User Stories, c’est aussi faire des choix pour le bien du produit.

Manager la conception de ses User Stories

Afin d’avoir une vision sur le cycle de conception des User Stories et d’être plus efficace, le Product Owner peut représenter le processus sous la forme d’un Kanban, disposant par exemple des étapes À FAIRE > RECHERCHE UTILISATEUR > ATELIERS INTERNES > WIREFRAMES > DÉCOUPAGE > PRÊT À RÉDIGER.

Illustré grâce à du management visuel, ce Kanban peut également faire l’objet de stand-up meetings de conception. Cette méthode permet de suivre au mieux l’avancée des différents sujets fonctionnels, d’avoir une meilleure visibilité sur les travaux de défrichage en cours, d’identifier les blocages et d’être plus efficace lors de cette étape.

Après sa conception, comment rédiger une bonne User Story ?

Qui, quoi, pourquoi

Si différents modèles de formulation des User Stories existent, il est fondamental que le Product Owner en adopte un qui inclut les dimensions “qui”, “quoi” et “pourquoi”.

Indispensables, ces trois éléments permettent de structurer le contenu de telle sorte qu’il exprime clairement la valeur ajoutée de la fonctionnalité, mais aussi le bénéficiaire.

La formulation la plus simple et connue d’une User Story est donc :

• En tant que :
• Je veux :
• Afin de :

Sous leur format anglo-saxon, les User Stories se présentent sous la même forme :

• As a :
• I want to :
• So that :

À savoir que le “en tant que” ne désigne pas forcément un type d’utilisateur final du système, mais tout rôle concerné par le produit : utilisateur final d’un certain segment, testeur, développeur, administrateur, etc.

Niveau de détail d’une User Story

La User Story dépasse souvent le cadre de la simple phrase. Le Product Owner peut y ajouter tous les éléments qui vont permettre à l’équipe de développement de prendre en charge l’implémentation complète de la fonctionnalité, comme par exemple :

• les règles métiers
• les wireframes, maquettes et autres éléments graphiques de l’interface utilisateur
• les tests d’acceptance (au format Behaviour Driven Development ou Gehrkin) pour valider de manière objective et systématique si la User Story a été implémentée correctement

Chez Hubvisory, nous mixons BDD et Gherkin afin d’aboutir au format suivant pour nos User Stories :

Le framework de User Story que nous utilisons chez Hubvisory

Par ailleurs, chaque User Story s’inscrivant dans un groupe plus large - une Epic - constituant une fonctionnalité, il peut être nécessaire de référencer l’Epic à laquelle la User Story est liée.

Enfin, si l’équipe emploie un management visuel pour gérer ses tickets de développement, il est assez coutumier que seules des abréviations des User Stories soient notées sur les post-it, afin de pouvoir conserver une vue d’ensemble sur les Stories en développement.

Par exemple, pour une User Story “En tant qu’assuré, je veux pouvoir prendre un rendez-vous avec un expert afin de constater mon dommage de dégât des eaux”, on pourrait écrire sur le post-it quelque chose comme “Prise RDV expert”.

Il convient cependant de noter qu’une User Story ne se suffit pas à elle même et ne remplace en rien la rédaction de spécifications associées. Dans les pratiques agiles, la User Story reste un outil de communication tandis que les spécifications (techniques et fonctionnelles) viennent très largement la compléter et lui donner du corps.

S’assurer qu’une User Story est bien rédigée grâce à l’acronyme INVEST

Afin de vérifier que la User Story que l’on a rédigée est de qualité (et permettra donc de construire un produit tout aussi qualitatif), on peut chercher à respecter les 6 adjectifs qui composent l’acronyme INVEST :

• Independent : chaque User Story doit être la plus indépendante possible afin que son développement soit facilité.
• Negotiable : tant qu’elle n’a pas été embarquée dans le sprint, une User Story doit pouvoir être challengée
• Valuable : comme son nom l’indique, la User Story doit apporter de la valeur à l’utilisateur final.
• Estimable : une User Story doit pouvoir être estimable en story points, qui représentent un niveau de complexité pour l’équipe de développement.
• Small : Plus l’Epic aura été découpée, plus les User Stories qui s’y rattachent seront “petites” et plus elles seront simples à développer, tester et déployer.
• Testable : pour chaque User Story, des critères objectifs de tests doivent être mis en place afin de permettre à l’équipe d’évaluer si le développement est conforme.

Facile à retenir, INVEST permet de garder en tête les principales caractéristiques d’une User Story de qualité.

Qualifier l’état d’une User Story grâce à la DoR et la DoD

Acronymes un peu barbares, la DoR (Definition Of Ready) et la DOD (Definition of Done) permettent d’englober l’ensemble des critères que l’équipe définie pour qualifier l’état “Prête à développer” et l’état “Terminée” de la User Story.

Tirés du cadre méthodologique Scrum, ses artefacts permettent de valider collectivement le passage de la User Story d’un état à un autre.

Rédiger sa DoR

En français “Définition de prêt”, la DoR est un ensemble de critères qui déterminent si une User Story est prête à être traitée par l’équipe de développement.

Traditionnellement, on utilise les “6D” pour définir sa DoR. Pour être prête à être développée, la User Story doit ainsi être :

• Désirable : la Story doit apporter de la valeur à l’utilisateur
• Décomposée : la Story n’est plus au stade “Epic”, elle est suffisamment précise
• Débattue : la Story a été discutée en équipe lors des séances d’affinage, au cours de conversations
• Dérisquée : néologisme pour signifier que les risques sur cette Story ont été réduits.
• Démontrable : la fonctionnalité derrière la Story peut être présentée à la revue de sprint, lors de la démo.
• Et enfin, posséder une Définition de Fini

Si la User Story remplit l’ensemble de ses critères, elle sera alors “Ready to dev”, c’est à dire qu’elle pourra faire l’objet d’un travail dès l’itération à venir.

D’autres critères, plus en lien avec la rédaction de la Story peuvent également être inclus dans la DoR. On peut par exemple demander à ce que la Story contienne les éléments suivants :

• Titre / Résumé
• Règles métier
• Maquettes
• Règles d’interfaces
• Cas de tests
• Jeux de données
• Car d’erreurs (et les messages associés)

On peut également valider que les processus définis par l’équipe pour construire ses User Stories de qualité ont bien été suivis en demandant :

• Qu’une relecture des User Stories par un autre Product Owner ait été effectuée
• Qu’une relecture par au moins un membre de l’équipe ait été effectuée
• Que la Story soit estimée par les équipes de développement
• Que la Story ait été validée par le métier
• Que la valeur utilisateur ait été estimée par le métier

Rédiger sa DoD

En français “Définition de fini”, la DoD permet de définir si une User Story peut-être considérée comme terminée, car plus aucun travail en lien avec elle ne sera nécessaire.

Les critères mis en place dans la Definition of Done doivent permettre deux choses :

• de s’assurer que la User Story a totalement été développée
• de s’assurer que sa qualité d’implémentation a été testée

Les éléments qui peuvent définir la Definition of Done sont par exemple :

• Le passage avec succès des tests fonctionnels définis dans la User Story
• La réalisation des tests automatiques
• La réalisation d’une revue du code
• La mise à jour de la documentation technique
• La précision des équipements sur lesquels tester la fonctionnalité (OS, navigateurs, taille d’écran…)

La place de la DOR et de la DOD dans le cycle de vie de la User Story

Pourquoi définir une DoR et une DoD pour ses User Stories ?

Établir une DoR et une DoD aide l’équipe à s’engager sur le sprint à venir et à se cadrer.

La Definition of Ready doit permettre d’éviter à l’équipe de développement de commencer à travailler sur une User Story qui ne serait pas assez claire ou précise, ce qui engendrerait des allers-retours coûteux et chronophages.

Par ailleurs, instaurer une DoR oblige l’équipe à l’anticipation : pour pouvoir embarquer des Stories, elle doit préparer et affiner son backlog en amont de chaque Sprint, ce qui lui permet de mieux connaître ses User Stories, de les estimer avec davantage de certitude, et donc de plus facilement atteindre son engagement.

Quant à la Definition of Done, sa définition par l’équipe permet d’éviter de commencer trop de choses sans réellement les finir, ce qui pourrait nuire à la qualité du produit. En Scrum, il est également nécessaire qu’une User Story soit “done” pour qu’on puisse compter les points de vélocité de l’équipe, et donc de calculer sa productivité d’un sprint à l’autre.

De l’idée initiale à sa mise en production, nous avons vu qu’une User Story parcourt tout un cycle de vie. Et si sa création est soumise à de nombreuses contraintes, une User Story de qualité n’est pas qu’une User Story rédigée selon toutes les bonnes pratiques. C’est avant tout un outil de communication que l’équipe à su s’approprier, notamment en personnalisant sa structure à ses besoins.

Quelle que soit la forme de User Story choisie, celle-ci doit être connue et partagée de tous, afin que l’équipe soit alignée et que les User Stories deviennent un outil efficace et pérenne pour la création du produit.