Guide des user stories

Utilisées dans le domaine du développement logiciel Agile, les user stories permettent de cartographier l’expérience utilisateur et de scinder des projets de grande envergure en petites étapes plus faciles à gérer. Les équipes Agile évitent ainsi les problèmes courants liés au formatage, à la collaboration, à la flexibilité et à la dynamique.

Les user stories sont utiles au sens où elles permettent d’aller au-delà des détails techniques d’un produit pour s’assurer qu’il offre une réelle valeur ajoutée à celles et ceux qui vont l’utiliser. Elles établissent une compréhension mutuelle entre les parties prenantes du projet afin que tout le monde tende vers le même objectif.

Ce guide expose le rôle et les avantages des user stories, et explique comment les rédiger.

Nous aborderons les poins suivants :

• Que sont les user stories ?
• User stories et cas d’usage
• Avantages des user stories
• Qui doit rédiger les user stories ?
• Cycle de vie des user stories
• Comment rédiger des user stories ?
• Template et exemples de user stories
• Comment ajouter des détails à des user stories ?

Que sont les user stories ?

Une user story est un outil de développement qui capture des fonctionnalités du point de vue du public cible. Les équipes Agile rédigent des user stories sur des notes repositionnables ou des fiches cartonnées, puis suivent la progression sur un tableau blanc ou via un tableau Kanban.

Les user stories ont pour objet de fournir une description simple et claire de chaque exigence. Elles permettent de se concentrer sur l’essentiel, c’est-à-dire l’expérience utilisateur, plutôt que sur les détails techniques.

Les user stories ont été mentionnées pour la première fois dans le livre Extreme Programming Explained de Kent Beck, publié en 1999. En 2001, Ron Jeffries a ajouté le framework des 3C (carte, conversation et confirmation) au concept des user stories de Kent Beck. Bill Wake a créé la checklist INVEST en 2003, qui fournit aux équipes un ensemble de consignes faciles à retenir pour rédiger des user stories efficaces. Bien que ce soit Bill Wake qui en ait trouvé l’acronyme, cette checklist a été popularisée par Mike Cohn dans son livre User Stories Applied: For Agile Software Development, publié en 2004.

Les user stories ont fait des adeptes au sein des équipes de développement tout en conservant un caractère informel. Rédigées sur des fiches cartonnées ou des notes repositionnables pour faciliter la planification et les échanges, elles font passer le fond et la fonction avant l’esthétique.

Aujourd’hui, les équipes de développement utilisent la checklist INVEST pour rédiger des user stories utiles :

• Indépendante. Les user stories doivent être indépendantes les unes des autres. L’équipe peut ainsi travailler dessus dans n’importe quel ordre, sans que les modifications apportées à l’une d’elles n’affectent les autres.
• Négociable. Les user stories ne sont pas gravées dans le marbre. Elles sont itératives et peuvent évoluer à mesure que l’équipe recueille des informations.
• Valeur. Le but ultime du produit que vous développez est d’apporter de la valeur ajoutée au public cible. Si une story ne procure pas de valeur, inutile d’y consacrer du temps.
• Estimable. Vous devez être en mesure d’estimer la taille d’une user story afin de déterminer comment prioriser les tâches et planifier le travail.
• Suffisamment petite. Les user stories doivent être suffisamment petites pour que l’équipe de développement puisse les programmer et les tester en une seule itération, généralement en trois jours.
• Testable. Chaque user story doit respecter un ensemble de critères permettant de déterminer si elle est prête ou nécessite des modifications.

User stories et cas d’usage

Les user stories et les cas d’usage sont utilisés par les équipes de développement pour définir les configurations requises, mais ont des finalités différentes. Ces deux concepts décrivent l’expérience utilisateur, mais ne sont pas interchangeables. Ivar Jacobson a inventé le concept des cas d’usage dans les années 1980 pour décrire le comportement d’un système et la séquence des interactions nécessaires entre un utilisateur ou une utilisatrice et le système.

Un cas d’usage décrit souvent des étapes supplémentaires, telles que les conditions préalables requises avant le début du cas d’usage. Les user stories sont, quant à elles, des descriptions simples et succinctes qui se focalisent sur l’essence même d’une exigence. Moins détaillées que les cas d’usage, elles sont surtout utilisées pour entamer la conversation et favoriser la collaboration.

Avantages des user stories

La décomposition d’un projet de grande ampleur en petites user stories facilite son exécution. Les user stories aident également les équipes de développement Agile à :

1. Éviter les risques de confusion grâce à un format simple. Comme les user stories sont concises et non techniques, tout le monde peut les comprendre. Ce format simplifié élimine la complexité et permet à chaque partie prenante de cerner les besoins du public cible.
2. Se concentrer sur l’utilisateur ou l’utilisatrice. Les user stories permettent aux équipes de développement à se focaliser davantage sur le but d’une solution, à savoir aider le public cible, que sur les fonctionnalités.
3. Favoriser la collaboration. Les user stories simplifient considérablement la collaboration entre les membres d’une équipe en clarifiant les besoins des utilisateurs et des utilisatrices, ce qui contribue à rationaliser le processus de développement.
4. Faire émerger des solutions originales. Les user stories ne prescrivent pas une solution, mais se concentrent sur un besoin. Les équipes de développement peuvent ainsi sortir des sentiers battus et créer des solutions plus innovantes qui répondent de façon optimale aux besoins des utilisateurs et des utilisatrices.
5. Gagner en souplesse. Extrêmement flexibles, les user stories peuvent être enrichies à mesure que vous en savez plus sur la solution ou les besoins du public cible. Les équipes Agile peuvent suivre les changements et s’y adapter.
6. Créer une dynamique. Concises et utiles, les user stories favorisent un développement incrémentiel et un flux continu de victoires pour votre équipe. Les spécialistes du développement peuvent suivre leur progression et leurs réalisations en temps réel, ce qui crée une dynamique au sein de l’équipe.

Qui doit rédiger les user stories ?

Les user stories sont généralement rédigées durant la phase de planification d’un projet. Toutefois, il est parfois nécessaire de les modifier ou d’en ajouter, notamment lorsque de nouvelles fonctionnalités sont créées ou que les exigences évoluent.

Bien que techniquement, n’importe qui puisse rédiger des user stories, ce sont généralement les responsables produit qui les créent et les gèrent. C’est donc la personne chargée de la vision du produit qui rédige les user stories initiales. Durant le projet, les membres de l’équipe de développement peuvent également en rédiger, surtout s’ils doivent scinder de grandes étapes techniques en stories plus faciles à gérer.

Il n’est pas rare que des parties prenantes telles que la clientèle ou la direction rédigent aussi des user stories, mais le dernier mot revient généralement à la personne responsable du produit.

Cycle de vie des user stories

Au cours d’un projet de développement logiciel, chaque user story passe par six états :

1. En attente

À cette étape, vous rédigez une description succincte des user stories. Il n’y a pas encore d’exigences détaillées. La story reste dans le backlog jusqu’à ce qu’une équipe s’en charge ou la rejette.

2. À faire

Lorsque l’équipe choisit une story, elle l’ajoute dans sa liste de tâches, ce qui signifie qu’elle est prête à exécuter. À cette étape, l’équipe place la tâche dans un sprint et l’ajoute à son planning.

3. Discussion

Pour exécuter la user story, l’équipe doit discuter de ses critères. Elle s’accorde sur les exigences, les wireframes et les storyboards afin de définir les détails de la user story.

4. Développement

À l’étape du développement, l’équipe de programmation code, teste et intègre la story en s’assurant qu’elle répond à la demande de l’utilisateur ou de l’utilisatrice.

5. Validation

Il s’agit de l’étape de test. En fonction de vos workflows, la solution peut être testée par un autre membre de l’équipe de développement, par la personne responsable du produit, voire par l’utilisateur ou l’utilisatrice. L’objectif est de confirmer que la fonctionnalité répond aux exigences. Sinon, elle retourne en développement jusqu’à ce qu’elle soit validée.

6. Terminé

À ce stade, la user story a passé tous les tests avec succès, et l’équipe l’ajoute à la version suivante.

Comment rédiger des user stories ?

La simplicité est le maître-mot des user stories. Appliquez les cinq conseils suivants pour rédiger des user stories efficaces pour votre équipe de développement :

1. Définissez l’état « terminé ». Une story est généralement terminée lorsque l’utilisateur ou l’utilisatrice peut accomplir la tâche en question. Il est donc important de préciser ce que « terminé » signifie. Vous pourrez ainsi plus facilement boucler la boucle pour chaque user story.
2. Envisagez de créer plusieurs stories. Si vous comptez plusieurs utilisateurs et utilisatrices, rédigez des stories distinctes pour chacun d’eux et chacune d’elles afin de répondre à leurs besoins.
3. Précisez les tâches et sous-tâches. En scindant un projet de grande ampleur en petites tâches, vous pouvez les déléguer et travailler indépendamment sur chacune d’elles. Cette démarche simplifie également le suivi de la progression et des résultats de l’équipe.
4. Rédigez une story pour chaque étape d’un processus complexe. Si une user story comprend un processus complexe, scindez-la en petites stories. Vous devrez peut-être ajouter des notes repositionnables sur votre tableau, mais le travail sera beaucoup plus facile à gérer.
5. Encouragez et prenez en compte les commentaires. La collaboration et l’itération sont les clés du développement Agile. Modifiez les user stories en fonction des commentaires et des données afin de pouvoir créer un produit de grande qualité.

S’il est utile de savoir créer des user stories, la tâche peut néanmoins sembler ardue pour celles et ceux qui n’en ont jamais rédigées. Examinons quelques exemples concrets de user stories efficaces.

Template et exemples de user stories

Les user stories sont souvent exprimées dans un template simple : « En tant que [profil], je [souhaite], [afin] ». La partie [profil] indique qui est l’utilisateur ou l’utilisatrice, par exemple un père ou une mère qui achète des vêtements pour enfant en ligne, ou un membre d’une entreprise qui a besoin d’un logiciel de comptabilité. La partie [souhaite] indique la fonctionnalité désirée par le profil, et la partie [afin] explique la raison pour laquelle elle est importante pour cette personne.

Par exemple :

• En tant que [gérant ou gérante d’un restaurant], je souhaite [actualiser le plat du jour dans mon menu digital] afin que [la clientèle puisse le connaître sans appeler le restaurant].
• En tant que [personne enregistrée], je souhaite [pouvoir réinitialiser mon mot de passe] afin de [pouvoir accéder à mon compte sans contacter le service clientèle].
• En tant que [acheteur ou acheteuse en ligne], je souhaite [filtrer les produits par prix] afin de [pouvoir trouver facilement les produits qui correspondent à mon budget].

Bien que cette structure ne soit pas obligatoire, elle aide à définir l’état « terminé » d’une user story. Si la solution apporte la valeur attendue, vous pouvez considérer la story comme terminée.

Comment ajouter des détails à des user stories ?

Vous savez à présent comment rédiger des user stories efficaces, mais peut-être avez-vous l’impression qu’il manque encore certains détails. Il existe deux façons de compléter une user story : en la scindant en stories plus petites ou en ajoutant des critères d’acceptation à l’aide des 3C.

Par exemple, la user story « En tant que [responsable marketing], je souhaite [prévisualiser les modifications apportées à mes blogs] afin de [m’assurer qu’elles s’affichent correctement] » est trop vague du point de vue du développement. Scindez-la en user stories plus petites. Par exemple : « En tant que [responsable marketing], je souhaite [avoir un panneau de prévisualisation dans le système de publication des blogs] afin de [pouvoir prévisualiser le contenu avant sa mise en ligne] ».

Vous pouvez également affiner les user stories à l’aide des 3C :

1. Carte. Il s’agit de la user story écrite qui suit le template concis « En tant que [profil], je [souhaite], [afin] ». À ce stade, la story n’est qu’un simple rappel et comporte peu de détails.
2. Conversation. Il s’agit de la discussion entre l’équipe, les utilisateurs et utilisatrices, et la personne responsable du produit. Elle se concentre sur la valeur ajoutée réelle, ainsi que sur des informations techniques plus détaillées et les exigences de test.
3. Confirmation. Durant la phase de confirmation, l’équipe s’accorde sur les critères d’acceptation qui indiqueront quand une story est terminée. Cette séquence dissipe les doutes et établit clairement si les exigences sont satisfaites.

Prise en charge simplifiée des user stories

Les user stories permettent de scinder des projets complexes et de grande ampleur en tâches plus faciles à exécuter. Elles évitent les risques de confusion et aident les équipes de développement Agile à créer des solutions utiles.

Au moment de vous lancer, explorez les solutions qui vous permettront de dépasser les attentes de vos utilisateurs et utilisatrices. Adobe Workfront rend vos objectifs visibles et permet ainsi à votre équipe de prioriser les tâches, de suivre l’état d’avancement et de mesurer les résultats. Cette solution tout-en-un permet de suivre les user stories, les sprints et les diagrammes d’avancement depuis un tableau de bord intuitif.

Suivez la visite guidée d’Adobe Workfront ou regardez la vidéo de présentation pour en savoir plus.