Le récit utilisateur (la user story), élément essentiel de l'agilité.

Comment rédiger des User Stories efficaces pour une meilleure collaboration et des fonctionnalités orientées utilisateur.

 2 nov 2024 ·   6 min ·  

Table des matières
  1. Qu’est-ce qu’une bonne User Story ?
  2. Format d’écriture des « User Stories ».
  3. Comment rédiger une bonne User Story en suivant les directives INVEST
  4. Qu’est-ce qu’un critère d’acceptance et comment bien le définir ?
    1. Ce qu’un critère d’acceptance ne doit pas être
  5. Exemples concrets de critères d’acceptance
    1. Exemple 1
      1. User Story
      2. Critères d’Acceptance
      3. Ce que ces critères ne doivent pas être
    2. Exemple 2
      1. User Story
      2. Critères d’Acceptance
      3. Ce que ces critères ne doivent pas être
  6. Sources

« Un récit utilisateur est une brève description d’un résultat pour un utilisateur spécifique, conduisant à une conversation pour obtenir plus de précisions ».1

Qu’est-ce qu’une bonne User Story ?

Une user story ne cherche pas à être exhaustive ; elle est avant tout un point de départ pour une « conversation » avec l’équipe de développement. Les éléments clés de cette définition sont donc « conversation » et « résultat ».

  • Conversation : Une user story initie un échange entre l’auteur et les développeurs, car les mots seuls ne suffisent pas toujours à transmettre fidèlement les idées ou les besoins.

  • Résultat : Contrairement à une spécification fonctionnelle classique, une user story laisse plus de flexibilité aux développeurs. Plutôt que de suivre une matrice de traçabilité rigide, elle s’inscrit dans une logique de résultats visés (outcomes) plutôt que de simples données de sortie (outputs).

    • Outputs : Ils représentent des produits ou fonctionnalités spécifiques, facilement mesurables et tangibles, aboutissant à une action concrète. Exemple : intégrer un bouton « PayPal » pour effectuer des paiements en ligne — mais on pourrait aussi bien choisir d’autres options comme « Mastercard » ou « Stripe ».

    • Outcomes : Ils sont davantage orientés vers l’objectif final à atteindre, sans nécessairement se limiter à un output particulier. Exemple : mettre en place un système de paiement en ligne, sans imposer un moyen de paiement spécifique.

Note
Quand l’output est bien défini, il est possible de s’y limiter directement sans passer par un outcome.

Une user story est donc une description concise d’une action souhaitée par l’utilisateur sur un produit ou service. Elle est en général rédigée par le Product Owner, bien qu’elle puisse être proposée par un membre de l’équipe ou un acteur clé. Cependant, le Product Owner en reste responsable.

Format d’écriture des « User Stories ».

Les User Stories utilisent un format d’écriture exprimé au travers d’un technique que le PMI appelle scénarii d’utilisation :

  • En tant que : on précise le « qui », c’est-à-dire le rôle de celui ou celle qui va manipuler la fonctionnalité du logiciel que l’on cherche à concevoir ;
  • Je souhaite : on précise le « quoi » (l’outcomes), c’est-à-dire l’action qui va produire un changement de système ou un changement de comportement comme précisée un peu plus bas dans cet article ;
  • Afin que : on précise le « pourquoi » c’est-à-dire le bénéfice concret chez l’utilisateur recherché.

Voici un exemple très simple pour l’application de messagerie « WhatsApp » :

En tant qu’utilisateur de l’application de messagerie
Je veux pouvoir rédiger des messages écrits asynchrones à mes contacts
Afin que je puisse communiquer gratuitement avec eux en ligne.

Comment rédiger une bonne User Story en suivant les directives INVEST

L’acronyme INVEST aide à se rappeler d’un ensemble de critères largement acceptés, ou d’une liste de vérification, pour évaluer la qualité d’une user story. Si la story ne satisfait pas à l’un de ces critères, l’équipe peut décider de la reformuler ou même de la réécrire (ce qui se traduit souvent par déchirer l’ancienne carte de story et en rédiger une nouvelle).

  1. Indépendante : Chaque User Story doit représenter un ensemble de valeurs métiers distinctes et indépendantes, de manière à ce qu’elle puisse être publiée seule tout en apportant une valeur ajoutée par rapport à l’état précédent.

  2. Négociable : Bien que l’objectif final soit décrit de manière claire, les moyens pour atteindre cet objectif doivent être négociables – entre le Product Owner et l’équipe de développement, le Product Owner et le client, ou tout autre acteur impliqué – pour éviter des contraintes irréalistes sur la fonctionnalité ou la caractéristique.

  3. Précieuse (Valuable) : La valeur métier de toute User Story doit être facilement identifiable en lisant la story, et chaque story doit représenter une valeur pour un type spécifique d’utilisateur.

  4. Estimable : Il doit y avoir suffisamment d’informations pour permettre une estimation de la taille d’une story afin de planifier et de s’engager correctement sur le travail (sans pour autant en savoir trop).

  5. Petite (Small) : Les User Stories doivent être assez petites pour être terminées au cours d’un sprint.

  6. Testable : Tous les membres de l’équipe doivent disposer d’un moyen clair et précis pour vérifier si une User Story est achevée.

À noter
Les directives INVEST sont des critères rapides pour évaluer la qualité des user stories. Elles ont été introduites dans un article de Bill Wake, qui a également adapté l’acronyme SMART (Spécifique, Mesurable, Atteignable, Pertinent, Limité dans le temps) pour les tâches résultant de la décomposition technique des user stories.

Qu’est-ce qu’un critère d’acceptance et comment bien le définir ?

Les critères d’acceptance sont des éléments clés dans le développement agile. Ils clarifient les attentes et définissent les conditions que chaque user story doit remplir pour être considérée comme terminée et répondant aux besoins du client. Bien définis, ils favorisent une communication efficace entre les parties prenantes (Product Owner, équipe de développement, etc.) et garantissent que les fonctionnalités livrées répondent aux objectifs métiers.

Un critère d’acceptance est une condition ou un ensemble de conditions précises qui doivent être remplies pour que le Product Owner considère qu’une user story est complète et fonctionnelle. Il sert de base à la fois pour le développement et pour les tests de validation, afin de s’assurer que l’histoire utilisateur répond aux attentes.

Un bon critère d’acceptance est :

  • Clair et précis : Il doit être facilement compréhensible par tous les membres de l’équipe.

  • Testable : Il doit permettre une vérification objective, par le biais de tests concrets, que la fonctionnalité est bien implémentée.

  • Orienté utilisateur : Il doit refléter les besoins de l’utilisateur final, pas seulement les aspects techniques.

  • Mesurable : Il doit être possible de déterminer si la condition est remplie ou non.

Ce qu’un critère d’acceptance ne doit pas être

Les critères d’acceptance doivent éviter certaines erreurs courantes pour remplir efficacement leur rôle. Voici ce qu’ils ne doivent pas être :

  • Trop vagues ou subjectifs : Des critères comme “facile à utiliser” ou “rapide” ne permettent pas de définir des conditions objectives pour la réussite de la story.

  • Trop techniques : Les critères d’acceptance doivent se concentrer sur le “quoi” et non le “comment”. Par exemple, un critère d’acceptance ne devrait pas détailler les étapes de développement ni les solutions techniques spécifiques.

  • Trop nombreux : Les critères d’acceptance doivent rester simples et concis. Trop de critères peuvent signifier que la story est trop complexe et mérite d’être décomposée en plusieurs stories.

Exemples concrets de critères d’acceptance

Exemple 1

User Story

En tant qu’utilisateur,
Je veux pouvoir réinitialiser mon mot de passe
Pour accéder à mon compte en cas d’oubli.

Critères d’Acceptance

  1. Si l’utilisateur clique sur “Mot de passe oublié”, un champ pour saisir son adresse email apparaît.
  2. Après avoir saisi une adresse email valide, l’utilisateur reçoit un email contenant un lien de réinitialisation du mot de passe.
  3. Le lien de réinitialisation expire après 24 heures.
  4. Si l’utilisateur utilise un lien expiré, un message d’erreur s’affiche l’invitant à redemander une réinitialisation.

Ce que ces critères ne doivent pas être

  • “L’email est envoyé instantanément” : Ce type de critère impose une contrainte technique sans que cela ne soit réellement important pour l’utilisateur.
  • “Le lien de réinitialisation est généré par le service X” : Ici, il s’agit d’un détail technique qui n’a pas d’impact direct pour l’utilisateur.

Exemple 2

User Story

En tant qu’administrateur,
je veux pouvoir exporter la liste des utilisateurs en fichier CSV.

Critères d’Acceptance

  1. Lorsqu’un administrateur clique sur “Exporter”, un fichier CSV contenant les informations des utilisateurs est généré et téléchargeable.
  2. Le fichier CSV contient les colonnes : Nom, Prénom, Email, Date de création.
  3. Le fichier doit inclure uniquement les utilisateurs actifs.

Ce que ces critères ne doivent pas être

  • “Utiliser la bibliothèque Y pour générer le fichier CSV” : Cela concerne la mise en œuvre technique, non visible pour l’utilisateur.
  • “Le fichier est généré en moins de 2 secondes” : Si la rapidité est essentielle, elle peut être définie comme une contrainte séparée, mais cela ne constitue pas en soi un critère d’acceptance.

Sources

  1. Source : PMBOK (Project Management Body of Knowledge). ↩

Articles similaires

Partage et commentaires

Partager cet article sur :  Mastodon  X (Twitter)  Facebook  LinkedIn  Reddit

Vous pouvez commenter cet article grâce à ce fil de discussion sur Mastodon (avec Mastodon ou un autre compte ActivityPub/​Fediverse).