User stories (récits utilisateur)
Décrivez ce qu'il faut construire sous forme de petits besoins testables, rédigés du côté de l'usager, pour que l'équipe construise la bonne chose et sache quand c'est terminé.
- Durée
- 45 min
- Participants
- 3–6
- Type de travail
- Planifier
En bref
Une user story est une courte formulation d'un besoin, écrite « En tant que [usager], j'ai besoin de [quelque chose], afin de [raison] », avec des critères d'acceptation qui disent quand elle est terminée. Partez de la recherche, regroupez les stories liées en epics, découpez les plus grosses et convenez des critères avec ceux qui les construiront et les testeront.
De quoi s'agit-il
Une user story décrit un morceau de travail du point de vue de la personne qui l'utilisera, plutôt que comme une tâche technique. Elle comporte trois parties : qui est l'usager, ce dont il a besoin et pourquoi. La partie « afin de » est la plus importante, car elle dit à l'équipe quel problème le travail résout et lui permet de proposer une meilleure façon de le résoudre. Chaque story porte des critères d'acceptation : une courte liste de conditions qui doivent être vraies pour qu'elle soit considérée comme terminée.
Les user stories viennent des pratiques agiles de développement logiciel et ont été utilisées pour la première fois en Extreme Programming à la fin des années 1990. Elles sont aujourd'hui la norme dans les équipes de services numériques, y compris dans l'administration. Le GOV.UK Service Manual britannique emploie la formule « j'ai besoin de » plutôt que « je veux », pour rester centré sur les besoins réels. Les grosses stories qui couvrent un objectif entier s'appellent des epics et se découpent en stories plus petites, qu'on peut construire et tester en peu de temps. Dans cette fiche, vous consignez l'usager, le besoin, la raison, les critères d'acceptation, l'epic de rattachement et les preuves qui fondent la story.
Quand l'utiliser
À utiliser quand
- Vous avez terminé la recherche et la conception et devez les transformer en une liste de travail qu'une équipe de réalisation peut construire.
- Un cahier des charges est long et technique, et personne ne sait dire quelles parties comptent le plus pour les usagers.
- Vous préparez la première version d'un nouveau service et devez vous accorder sur ce qui est inclus et ce qui peut attendre.
- Les équipes métier, politiques et techniques décrivent le même service avec des mots différents et ne cessent de mal se comprendre.
- Il vous faut des conditions claires pour les tests, afin que tout le monde s'accorde sur le moment où une fonctionnalité est terminée.
À éviter quand
- Vous ne savez pas encore qui sont vos usagers ni ce dont ils ont besoin. Faites d'abord la recherche, sinon les stories décriront des suppositions.
- Le travail est purement technique, sans changement visible pour l'usager, comme la mise à niveau d'une base de données. Une simple description de tâche est plus claire.
- Vous explorez encore des idées très différentes. Les stories figent le détail trop tôt ; commencez par un storyboard ou un prototype.
Ce qu'il vous faut
- Durée
- Environ 45 minutes pour rédiger et relire les stories d'un epic ; davantage pour un service entier.
- Participants
- 3 à 6 personnes : un responsable produit ou de service, quelqu'un issu de la recherche, et au moins une personne qui construira et une qui testera.
- Matériel
- Les constats de recherche ou une carte d'expérience, des fiches bristol ou un tableau partagé, et un modèle simple reprenant les six champs de la fiche.
Comment la mener
Étape 1: Partir de l'objectif de l'usager
Écrivez en haut du tableau l'objectif global d'un groupe d'usagers, par exemple « un affilié demande sa pension de retraite ». Ce sera l'epic. Affichez à côté la recherche utile, comme des citations, une carte d'expérience ou un énoncé de point de vue, pour que les stories restent rattachées aux preuves.
Étape 2: Nommer précisément les usagers
Listez les types d'usagers concernés par l'objectif, en termes simples : « un affilié qui part à la retraite cette année », « l'employeur d'un affilié », « un gestionnaire retraite ». Évitez « en tant qu'usager » et « en tant que système » : ils masquent à qui appartient le besoin. Les agents sont aussi des usagers et ont leurs propres stories.
Étape 3: Rédiger les stories
Demandez à chacun d'écrire des stories sur des fiches séparées, sous la forme « En tant que…, j'ai besoin de…, afin de… ». Formulez le besoin dans les termes de l'usager, pas comme un écran ou un bouton : « j'ai besoin de savoir quels documents envoyer » plutôt que « j'ai besoin d'une page de dépôt de documents ». Visez un besoin par fiche.
Étape 4: Vérifier le « afin de »
Lisez chaque fiche à voix haute et demandez-vous si la raison est réelle et précise. « Afin de pouvoir faire ma demande » n'apporte rien. « Afin que mon premier versement ne soit pas retardé » dit à l'équipe à quoi ressemble la réussite. Si personne ne sait dire pourquoi l'usager en a besoin, retirez la fiche ou marquez-la comme hypothèse à vérifier.
Étape 5: Découper les grosses stories
Si une story demanderait à une équipe plus de quelques jours pour être construite et testée, découpez-la. Les bonnes façons de découper : par type d'usager, par moment du parcours, par cas simple et cas complexe, ou par chemin principal d'abord et exceptions ensuite. Gardez les stories découpées sous le même epic.
Étape 6: Rédiger les critères d'acceptation
Pour chaque story, convenez de trois à six conditions qui doivent être vraies une fois terminée, rédigées pour qu'un testeur puisse les vérifier. Un modèle utile : « Étant donné [situation], quand [action], alors [résultat] ». Incluez les chemins d'erreur, comme un document manquant ou un numéro erroné, pas seulement le chemin principal.
Étape 7: Ordonner et consigner
Disposez les stories sous l'epic dans l'ordre où les usagers les rencontrent, puis indiquez celles qui sont nécessaires à la première version. Consignez chaque story avec ses preuves et ses critères dans le backlog de l'équipe, et convenez de qui relira les stories avec l'équipe de recherche avant le début de la réalisation.
Exemple concret
Une caisse publique de retraite recevait environ 3 400 demandes de pension par mois, presque toutes sur papier. Le traitement prenait en moyenne 47 jours, et 38 % des dossiers étaient renvoyés au moins une fois à l'affilié pour information manquante ou erronée. La caisse prévoyait un service en ligne et disposait d'un cahier des charges de 400 pages que l'équipe de réalisation avait du mal à exploiter.
Cinq personnes se sont réunies 45 minutes : la responsable du service, une chercheuse UX, un gestionnaire retraite, un développeur et une testeuse. Elles ont pris l'epic « un affilié demande sa pension de retraite » et placé à côté des citations d'entretiens et la carte d'expérience.
Elles ont listé quatre usagers : un affilié qui part à la retraite cette année, l'employeur d'un affilié, un gestionnaire retraite et un proche mandaté par l'affilié. Le premier jet a produit 26 fiches.
La vérification du « afin de » a supprimé quatre fiches qui ne faisaient que reformuler l'action. Elle a aussi transformé « En tant qu'affilié, j'ai besoin de téléverser mon attestation de services » en « En tant qu'affilié qui part à la retraite cette année, j'ai besoin de savoir que mon employeur a déjà confirmé mes périodes de service, afin de ne pas avoir à réunir moi-même une attestation ».
La story sur le calcul de la pension était trop grosse. L'équipe l'a découpée en trois : affiliés avec un seul employeur, affiliés avec plusieurs employeurs, affiliés avec des interruptions de cotisation, et n'a retenu que la première pour la version 1.
Les critères d'acceptation de la story sur les périodes de service comprenaient « Étant donné que l'employeur a confirmé les périodes, quand l'affilié se connecte, alors les périodes s'affichent et peuvent être validées » et « Étant donné que les périodes manquent, quand l'affilié se connecte, alors il voit qui contacter et le dossier est signalé à un gestionnaire ».
Le backlog final de l'epic comptait 18 stories, dont 11 retenues pour la première version. L'équipe a programmé une relecture avec la chercheuse avant le premier sprint.
À titre illustratifConseils et erreurs
Conseils
- Formulez le besoin comme quelque chose que l'usager veut accomplir, pas comme une fonctionnalité. Cela laisse à l'équipe la place de trouver une solution plus simple.
- Gardez des stories assez petites pour être construites et testées en un sprint ou une semaine. Les grosses stories cachent des risques.
- Rédigez aussi des stories pour les agents. Les gestionnaires qui traitent les dossiers ont des besoins qui façonnent tout le service.
- Rattachez chaque story aux preuves qui la fondent, pour que chacun puisse vérifier d'où vient un besoin.
Erreurs fréquentes
- Écrire « En tant qu'usager » pour tout, ce qui masque les besoins différents de personnes différentes.
- Transformer une tâche technique en story en ajoutant « En tant que système », ce qui va à l'encontre du format.
- Omettre les critères d'acceptation, si bien que l'équipe et les testeurs décident chacun de leur côté ce que « terminé » veut dire.
- Rédiger seul tout le backlog à son bureau et le transmettre, au lieu de l'élaborer et de le vérifier avec l'équipe.
Ce que vous obtenez
Vous repartez avec un epic découpé en petites user stories, chacune nommant l'usager, le besoin et la raison, avec des critères d'acceptation, un lien vers les preuves et une marque pour la première version. Les stories vont directement dans le backlog de l'équipe de réalisation. Une feuille de route aide à séquencer les epics dans le temps, et un storyboard peut montrer comment les stories composent une seule expérience.
Questions fréquentes
Pourquoi GOV.UK écrit-il « j'ai besoin de » plutôt que « je veux » dans les user stories ?
« J'ai besoin de » garde l'attention sur ce que les usagers doivent pouvoir faire pour obtenir le résultat, plutôt que sur des préférences. Cela pousse les équipes à demander la preuve que le besoin est réel. Beaucoup d'équipes hors de l'administration utilisent « je veux » ; la structure de la story reste la même.
Quelle différence entre un epic et une user story ?
Un epic est un objectif d'usager important, comme demander sa pension, trop gros pour être construit d'un seul coup. Une user story est une petite partie de cet objectif qu'une équipe peut construire et tester en quelques jours. Un epic contient en général plusieurs stories, parfois des dizaines.
Combien de critères d'acceptation par user story ?
En général trois à six. Moins peut signifier que la story est floue ou que des chemins d'erreur ont été oubliés. Beaucoup plus signifie souvent que la story est trop grosse et doit être découpée.
Fiche de l'outil
La fiche de travail que remplit votre équipe, une case par rubrique.
- Usager
- Besoin
- Afin de
- Critères d'acceptation
- Epic
- Preuves