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

Seize exemples de user stories annotées dans les domaines de l'authentification, du commerce électronique, des applications mobiles, des API et des bogues, les versions incorrectes étant présentées à côté de leurs réécritures afin que la différence soit clairement visible.

Seize exemples d’histoires utilisateur, tirés des domaines dans lesquels les équipes travaillent réellement : authentification, commerce électronique, mobile, API, bogues et outils internes. Chacune d’entre elles est annotée : il ne s’agit pas seulement de ce que dit l’histoire, mais aussi d’expliquer pourquoi les clauses relatives au rôle et aux avantages 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 ce 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 suit ici la structure « En tant que [rôle], je souhaite [objectif], afin que [avantage] », et toute user story de qualité peut passer directement à la phase de raffinement 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 mesurable ; ce cas peut donc être classé par ordre de priorité 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 d’adresses).

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 cela ne dit rien. Le rôle n’est pas attribué à une personne en particulier, et l’intérêt réitère 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 reformulation :

En tant que membre de l’équipe 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 à le retrouver chaque matin.

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

Commerce en ligne

4. Persistance du panier

En tant que client qui fait ses achats pendant ma 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 subtilement le contexte dans une seule clause.

5. Paiement en tant qu’invité

En tant que nouveau client, je souhaite passer commande 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 en expose l’avantage en toute franchise : 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 métrique déguisé en personnage de conte

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

Pourquoi cela ne fonctionne pas : pour deux raisons. « 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 une histoire.

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 succession de tranches comme celle-ci, 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 du jour 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 rôle qui détermine l’exigence. Le personnel administratif ne remarque jamais l’assistance hors ligne ; les techniciens de terrain, eux, y sont confrontés au quotidien. Lorsqu’on demande « À quel point est-on vraiment hors ligne ? » lors de la phase d’affinage, le rôle a déjà apporté la réponse : partout où leur travail 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 que les réponses de l’endpoint /events soient paginées, afin que ma synchronisation nocturne ne se solde pas par un délai d’expiration pour 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 permanence 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 l’article « Quand les histoires utilisateur ne sont pas l’outil adéquat ».

La reformulation (ce n’est pas une « user story », et c’est voulu) :

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. Objectif atteint lorsque : l’interface du prestataire est extraite, les deux prestataires existants fonctionnent derrière celle-ci et la suite de tests d’intégration est 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 à créer 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 manière sporadique avoir été facturés deux fois. Impossible de reproduire ce problème 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-bénéfice » (« En tant que client, je souhaite ne pas être facturé deux fois… ») serait certes vraie, mais inutile, et toute estimation ne ferait que refléter un espoir. La bonne approche consiste à réaliser un spike dans un délai défini : 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 périmètre 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 et les règles au format CSV, ennuyeux mais portable. Une bonne clause d’objectif fait le travail de conception gratuitement.

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 » ne constitue 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 qui n’a pas encore été posée au responsable.

La reformulation :

En tant que responsable de la livraison chargé de préparer la réunion de suivi 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 stories é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 démesurée (personne n’a vérifié l’ampleur du projet). 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 de ce format. Rédigez votre prochaine série de stories à l’aide du 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

Pouvez-vous donner un exemple d’histoire utilisateur ?

« 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 formulation 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 commençant par « 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 forme d’histoire utilisateur ?

Parfois. Si l’« utilisateur » est bien réel (un développeur d’intégration qui utilise votre API, un opérateur de garde), le format fonctionne tel quel. Si le seul rôle pertinent est « l’équipe », abandonnez les formules habituelles 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 la fiabilité de la vélocité. Un bug que personne ne parvient à reproduire ne peut l’être : il n’y a pas de périmètre à promettre, donc une story ne serait qu’une supposition accompagnée d’une clause relative aux avantages. Fixez 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 l’histoire, 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 le nombre de cinq, cela signifie que l’histoire en recouvre en réalité plusieurs, et les critères vous indiquent où la diviser.

Lectures complémentaires