Exemples d'histoires utilisateur : 16 histoires commentées, bonnes et mauvaises

Seize exemples d'histoires utilisateur couvrant l'authentification, le commerce électronique, les applications mobiles, les API et les bogues — chacun étant annoté, les mauvaises versions étant présentées à côté de leurs versions réécrites afin que la différence soit visible.

Seize exemples d’histoires utilisateur, tirés des domaines dans lesquels les équipes travaillent réellement : authentification, e-commerce, mobile, API, bogues et outils internes. Chacune est commentée — non seulement sur ce que dit l’histoire, mais aussi sur les raisons pour lesquelles les clauses de rôle et d’avantage ont toute leur raison d’être. Quatre d’entre elles sont délibérément mal rédigées et présentées à côté de leur version corrigée, car le moyen le plus rapide d’apprendre le format est d’observer ses échecs.

Si ce format vous est inconnu, commencez par Qu’est-ce qu’une user story ? — en résumé, chaque user story ici suit le modèle «En tant que [rôle], je souhaite [objectif], afin que [avantage] », et toute bonne user story pourrait passer directement à la phase d’affinage et à une session de planning poker.

Authentification et comptes

1. Connexion

En tant que client fidèle, je souhaite me connecter à l’aide de mon adresse e-mail et de mon mot de passe afin de pouvoir consulter l’historique de mes commandes.

Pourquoi cela fonctionne : ce rôle est précis. L’expression « client fidèle » vous indique que cette personne possède un compte, a déjà passé commande et a une raison de revenir — trois éléments dont un concepteur et un testeur peuvent tirer parti. L’expression « en tant qu’utilisateur » n’aurait fourni aucune de ces informations.

2. Réinitialisation du mot de passe

En tant qu’utilisateur dont l’accès a été bloqué, je souhaite réinitialiser mon mot de passe depuis l’écran de connexion, afin de pouvoir accéder à nouveau à mon compte sans avoir à contacter le service d’assistance.

Pourquoi cela fonctionne : la clause relative aux avantages mentionne un coût réel. Chaque réinitialisation traitée par le support technique représente un coût financier mesurable ; ce cas peut donc être priorisé par rapport à d’autres sur la base de données concrètes plutôt que d’impressions subjectives. Notez ce que la phrase ne mentionne pas : l’expiration des jetons, les limites de débit, le modèle d’e-mail. Ces détails relèvent des critères d’acceptation, rédigés lorsque l’équipe affinera la fonctionnalité :

  • Un e-mail de réinitialisation vous est envoyé dans les deux minutes suivant votre demande.
  • Le lien de réinitialisation expire au bout d’une heure et ne peut être utilisé qu’une seule fois.
  • Le formulaire renvoie la même réponse, que l’adresse e-mail existe ou non (pas de recherche de comptes).

3. Le récit circulaire

En tant qu’utilisateur, je souhaite me connecter afin de pouvoir accéder à l’application.

Pourquoi cela ne fonctionne pas : tous les champs sont remplis, mais rien n’est dit. Le rôle ne désigne personne en particulier, et l’avantage ne fait que reformuler l’objectif ; la clause « afin que » pourrait donc être supprimée sans perte d’information. Une histoire comme celle-ci passe le contrôle de format tout en contournant toute la réflexion que ce format est censé imposer.

La nouvelle version :

En tant que membre de l’équipe de projet revenant en cours de sprint, je souhaite accéder directement au tableau que j’avais consulté en dernier avant de me déconnecter, afin de ne pas avoir à y revenir chaque matin.

Voilà donc une personne, un moment et un avantage que l’on pourrait mettre en balance avec d’autres tâches.

Commerce en ligne

4. Persistance du panier

En tant qu’acheteur qui fait ses achats pendant sa pause déjeuner, je souhaite que mon panier conserve les articles que j’y ai ajoutés jusqu’à ce que je revienne ce soir, afin de ne pas avoir à tout rechercher à nouveau.

Pourquoi cela fonctionne : ce rôle véhicule un scénario. « Naviguer sur Internet pendant ma pause déjeuner » explique pourquoi les paniers sont abandonnés en cours de parcours, ce qui indique à l’équipe que la fenêtre de persistance qui importe se mesure en heures, et non en secondes. Un rôle bien choisi permet d’intégrer le contexte dans une seule clause.

5. Paiement en tant qu’invité

En tant que nouvel acheteur, je souhaite passer à la caisse sans créer de compte, afin de pouvoir finaliser mon achat avant de changer d’avis.

Pourquoi cela fonctionne : cela présente un argument de vente (les comptes sont facultatifs) et expose clairement l’avantage réel — l’hésitation empêche les premiers achats. Des explications aussi claires permettent également de mettre en évidence les désaccords dès le début : si l’entreprise souhaite que chaque acheteur dispose d’un compte, ce débat aura lieu lors de la phase de peaufinage, et non dans la pull request.

6. Le personnage qui porte un costume de conte

En tant qu’acheteur, je souhaite que le processus de paiement soit plus rapide et plus fluide, afin d’améliorer le taux de conversion.

Pourquoi cela ne fonctionne pas : à deux égards. « Plus rapide, plus propre » n’est pas une fonctionnalité que n’importe qui peut développer ou tester, et « l’amélioration du taux de conversion » est un avantage pour l’entreprise, pas pour le client — aucun client ne souhaite une conversion. Il s’agit là d’un trimestre de travail condensé en une seule phrase, ce qui en fait une épopée, et non un récit.

La réécriture (un extrait) :

En tant qu’acheteur sur mon téléphone, je souhaite que mon adresse de livraison soit renseignée automatiquement à partir de mon code postal, afin de pouvoir finaliser ma commande d’une seule main.

L’épopée se compose d’une série de tâches de ce type, chacune pouvant faire l’objet d’un test et suffisamment petite pour être gérée.

Mobile

7. Mode hors ligne

En tant que technicien de terrain, je souhaite que la fiche de travail d’aujourd’hui se charge sans connexion, afin de pouvoir continuer à travailler dans les sous-sols et les zones sans réseau.

Pourquoi cela fonctionne : c’est le poste qui détermine l’exigence. Le personnel administratif ne remarque jamais le travail hors ligne ; les techniciens de terrain, eux, y sont confrontés au quotidien. Lorsqu’on leur demande, au cours de la phase d’affinage, « À quel point le travail hors ligne est-il hors ligne ? », la réponse est déjà donnée par la nature même du poste : partout où leur mission les mène.

8. Préférences de notification

En tant qu’abonné recevant trois notifications push par jour, je souhaite pouvoir choisir les types d’alertes pour lesquels je souhaite recevoir des notifications, afin de ne plus avoir à désactiver les notifications de l’application dans son ensemble.

Pourquoi cela fonctionne : l’avantage identifie le mode de défaillance que l’histoire permet d’éviter. Les utilisateurs ne se plaignent pas du nombre de notifications ; ils désactivent les notifications de l’application et s’en vont discrètement. Une histoire qui identifie le comportement silencieux contre lequel elle se prémunit est une histoire dont l’équipe peut débattre en toute franchise.

API et travaux techniques

9. Pagination

En tant que développeur d’intégration, je souhaite obtenir des réponses paginées sur le point de terminaison /events, afin que ma synchronisation nocturne ne se solde pas par un délai d’expiration sur les comptes volumineux.

Pourquoi cela fonctionne : il s’agit là d’un cas d’utilisation technique légitime : le développeur est un véritable utilisateur externe ayant ses propres objectifs, et non l’équipe qui se met elle-même en scène dans la phrase. Les utilisateurs de l’API, les auteurs de plugins et les opérateurs de garde répondent tous à ce critère.

10. Limitation du débit

En tant qu’utilisateur de l’API, je souhaite recevoir une réponse 429 accompagnée d’un en-tête « Retry-After » lorsque j’atteins la limite de débit, afin que mon client puisse réduire la fréquence de ses requêtes au lieu de faire échouer l’ensemble de la tâche.

Pourquoi cela fonctionne : l’objectif est suffisamment précis pour constituer en soi le premier critère d’acceptation, et il s’agit toujours d’un quoi, et non d’un comment — rien ici ne dicte la manière dont le limiteur doit être mis en œuvre.

11. La refactorisation déguisée

En tant que développeur, je souhaite refactoriser le module de paiement afin que le code soit plus clair.

Pourquoi cela ne fonctionne pas : le rôle correspond à l’équipe, l’objectif est une activité plutôt qu’un résultat, et le terme « plus propre » ne peut pas faire l’objet d’un test. Il s’agit ici d’appliquer le format de l’histoire utilisateur à un contexte pour lequel il n’a pas été conçu — un cas abordé dans « Quand les histoires utilisateur ne sont pas l’outil adéquat ».

La reformulation (il ne s’agit pas d’une « user story », et ce, à dessein) :

Réduire la dépendance du module de paiement vis-à-vis des prestataires afin de pouvoir ajouter un nouveau prestataire de paiement sans modifier le cœur du processus de paiement. La tâche sera considérée comme terminée lorsque : l’interface du prestataire aura été extraite, que les deux prestataires existants fonctionneront derrière celle-ci et que la suite de tests d’intégration sera réussie sans modification.

Un sujet technique simple dont l’objectif est clairement défini l’emporte toujours sur une histoire pleine de fantaisie.

Est-ce un bug ou une fonctionnalité ?

12. L’insecte qui est une histoire

En tant que client ayant souscrit un abonnement annuel, je souhaite que ma facture indique la remise qui m’a été proposée, afin que le service financier puisse effectuer le rapprochement sans avoir à ouvrir de ticket d’assistance.

Pourquoi cela fonctionne : la cause est connue et la correction a une portée bien définie ; ce cas se comporte donc comme n’importe quelle autre story : on lui attribue des critères, une taille et une place dans le sprint. Le traitement des bogues permet de garantir que la vélocité reflète fidèlement l’utilisation réelle de la capacité ; le chapitre consacré aux points de story développe cet argument en détail.

13. Le bug qui n’en est pas un

Des clients signalent de temps à autre avoir été facturés deux fois. Impossible de reproduire ce phénomène de manière fiable.

Pourquoi ce n’est pas un scénario : il n’y a pas de marge de manœuvre pour faire une promesse. Une phrase de type « rôle-objectif-avantage » (« En tant que client, je souhaite ne pas être facturé deux fois… ») serait vraie mais inutile, et toute estimation ne ferait que refléter un espoir. La bonne approche consiste à mener un spike: mener une enquête pendant deux jours, présenter les conclusions, puis rédiger la véritable story pour la correction.

Outils internes et rapports

14. Outillage d’assistance

En tant qu’agent du service client sur un chat en direct, je souhaite pouvoir consulter les cinq dernières tentatives de connexion du client, afin de pouvoir distinguer d’un seul coup d’œil un mot de passe oublié d’un compte verrouillé.

Pourquoi cela fonctionne : les utilisateurs internes restent des utilisateurs. Le bénéfice se mesure en secondes par ticket, ce qui correspond exactement au type d’enjeu concret qui permet à cette tâche de rivaliser avec les tâches en contact avec la clientèle pour obtenir une place dans le sprint, au lieu d’être automatiquement écartée.

15. Exportations

En tant que chef d’équipe, je souhaite exporter le rapport de sprint au format CSV afin de pouvoir partager les résultats avec les parties prenantes qui ne disposent pas de compte.

Pourquoi cela fonctionne : la clause « afin que » définit discrètement le champ d’application du travail. Le partage en dehors de l’outil constitue la mission, ce qui exclut des solutions telles que les tableaux de bord intégrés à l’application ou les règles exprimées dans des fichiers CSV portables et peu attrayants. Une bonne clause d’objectif permet de réaliser gratuitement un travail de conception.

16. L’épopée de la visibilité

En tant que responsable, je souhaite disposer d’un tableau de bord récapitulant toutes les activités de l’équipe, afin d’avoir une bonne visibilité.

Pourquoi cela ne fonctionne pas : « tout » n’est pas un périmètre et la « visibilité » n’est pas un résultat — rien ici ne peut être développé, testé ou chiffré. Derrière une story comme celle-ci se cache une véritable question que l’on n’a pas encore posée au responsable.

La nouvelle version :

En tant que responsable de la livraison chargé de préparer la réunion d’état d’avancement du lundi, je souhaite disposer sur une seule page de l’objectif de sprint de chaque équipe ainsi que de son statut (rouge/orange/vert), afin de pouvoir signaler les tâches bloquées sans avoir à contacter chaque chef d’équipe.

C’est la même personne, le même instinct, mais cela s’inscrit désormais dans le cadre d’un sprint et le testeur sait quand le travail est terminé.

Ce que les meilleurs ont en commun

Passez en revue les douze qui fonctionnent. Chacun d’entre eux désigne une personne suffisamment précise pour avoir un avis, énonce un objectif que cette personne reconnaîtrait, et présente un avantage qui résiste à une question sincère du type « pourquoi ? ». Aucun d’entre eux ne contient de modalités de mise en œuvre, et aucun ne prétend être exhaustif — c’est à cela que servent les critères d’acceptation et la discussion de raffinement.

Ces quatre mauvaises histoires échouent de deux manières bien précises, ce qui est encourageant : soit l’avantage est circulaire (personne n’a vérifié pourquoi), soit la portée est gigantesque (personne n’a vérifié son ampleur). Ces deux types d’échec apparaissent dès que votre équipe tente d’estimer l’histoire, ce qui explique pourquoi les sessions d’estimation permettent de repérer les mauvaises histoires plus rapidement que n’importe quelle consigne de rédaction — un écart important entre les votes est le message d’erreur inhérent à ce format. Rédigez votre prochaine série de stories en suivant le modèle, puis présentez-les à l’équipe à l’aide du planning poker et voyez lesquelles font l’objet d’un consensus.

Foire aux questions

Pourriez-vous donner un exemple d’« user story » ?

« En tant que client fidèle, je souhaite me connecter avec mon adresse e-mail et mon mot de passe afin de pouvoir consulter l’historique de mes commandes. » Cette phrase désigne une personne spécifique, une fonctionnalité telle que cette personne la perçoit, ainsi que la raison pour laquelle il est pertinent de planifier ce travail. Cette structure en trois parties (rôle, objectif, avantage) correspond au format classique d’une user story.

Comment rédiger une bonne user story ?

Citez un rôle précis plutôt que « un utilisateur », formulez l’objectif en termes d’action effectuée par la personne plutôt que d’élément contenu dans le système, et terminez la clause « afin que » par un avantage qui résisterait à un « pourquoi ? » sincère. Ajoutez ensuite les critères d’acceptation, car la phrase décrivant l’histoire sert à lancer la conversation, et non à définir l’exigence.

Une tâche technique peut-elle être formulée sous la forme d’une « user story » ?

Parfois. Si l’« utilisateur » est bien réel — un développeur d’intégration qui utilise votre API, un opérateur de garde —, ce format fonctionne tel quel. Si le seul rôle pertinent est « l’équipe », abandonnez les artifices et rédigez un élément technique simple, avec un résultat nommé et des critères d’acceptation. La rigueur reste la même ; la structure de la phrase, elle, peut varier.

Les bogues doivent-ils être rédigés sous forme d’histoires utilisateur ?

Un bug dont la cause est connue et pour lequel il existe une solution claire peut l’être, et le signaler permet de garantir l’exactitude de la vélocité. Un bug que personne ne parvient à reproduire ne peut pas l’être : il n’y a aucune base sur laquelle s’appuyer pour faire une promesse, de sorte qu’une story ne serait alors qu’une supposition accompagnée d’une clause relative aux avantages. Définissez d’abord un délai pour l’investigation, puis rédigez la véritable story en fonction des résultats obtenus.

Quel doit être le niveau de détail d’une user story ?

Une phrase décrivant le scénario, puis trois à cinq critères d’acceptation. La phrase sert de point de départ à la discussion ; les critères résument ce qui a été décidé lors de cette discussion. Si la liste des critères dépasse cinq, cela signifie que le scénario en comprend plusieurs, et les critères vous indiquent où les séparer.

Lectures complémentaires