Histoires d'utilisateurs efficaces

Dans le développement agile, nous avons changé notre approche pour passer de la création de « fonctionnalités » à la fourniture de « valeur » à l'utilisateur.

Les récits d'utilisateurs sont le principal outil permettant de décrire le travail dans cette perspective axée sur la valeur.

Il ne s'agit pas de spécifications techniques détaillées, mais de brèves descriptions d'une fonctionnalité racontées du point de vue de l'utilisateur, expliquant qui a besoin de quoi, et pourquoi.

Elles aident l'équipe à comprendre le contexte et l'objectif du travail, en encourageant la conversation et la collaboration afin de trouver la meilleure solution.

En tant que coach Agile, il est essentiel d'apprendre à l'équipe, et en particulier au propriétaire du produit, à rédiger et à utiliser efficacement les récits d'utilisateurs.

Format (En tant que , je veux , pour )

Le format le plus courant pour rédiger des récits d'utilisateurs suit un modèle simple mais efficace :

En tant que , je souhaite , afin de .

En tant que : identifie qui bénéficiera de l'histoire (par exemple, « acheteur fréquent », « administrateur », « utilisateur non enregistré »).

Parfois, l'« utilisateur » peut même être un système interne, mais il doit toujours être lié en fin de compte à la valeur pour l'utilisateur final.

Je souhaite : décrivez ce que l'utilisateur souhaite pouvoir faire.

Il doit s'agir du véritable objectif de l'utilisateur, et non d'une action intermédiaire (par exemple, « recevoir des notifications » plutôt que « appuyer sur un bouton rouge »).

Afin que : expliquez la motivation derrière l'objectif, la valeur que l'utilisateur espère obtenir. Cette partie est cruciale pour comprendre l'importance et hiérarchiser l'histoire.

Il existe d'autres modèles (tels que Qui-Quoi-Pourquoi), mais tous cherchent à saisir ces trois éléments essentiels.

Se concentrer sur le problème, pas sur la solution

Une bonne histoire utilisateur décrit le problème que l'utilisateur doit résoudre ou l'objectif qu'il souhaite atteindre, sans prescrire la solution technique.

Il incombe à l'équipe de développement, en collaboration avec le propriétaire du produit et les autres parties prenantes, de trouver la meilleure façon de mettre en œuvre la solution.

Par exemple, au lieu de demander « créer un chatbot » (solution), l'histoire pourrait être « En tant qu'utilisateur rencontrant des problèmes techniques, je souhaite obtenir une assistance immédiate pour résoudre rapidement mon problème » (problème).

Cette approche encourage l'innovation et la créativité, permettant à l'équipe d'explorer différentes solutions (une section FAQ améliorée peut être plus efficace qu'un chatbot) et de se concentrer sur la fourniture de la valeur réelle dont l'utilisateur a besoin.

Critères d'acceptation (Donné-Quand-Alors)

Pour s'assurer qu'une histoire utilisateur a été correctement mise en œuvre et résout le problème prévu, on utilise les critères d'acceptation (CA).

Il s'agit d'un ensemble de conditions spécifiques et vérifiables qui doivent être remplies pour que l'histoire soit considérée comme « terminée ».

Contrairement à la définition de « fait » (DoD) qui est générale pour l'ensemble du travail, les AC sont uniques à chaque histoire utilisateur.

Un format courant pour rédiger les AC est Donné-Quand-Alors (Given-When-Then) :

• Étant donné (Given) : établit le contexte ou la condition préa