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

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 : 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 le format est d’observer ses échecs.

Si ce format vous est encore inconnu, commencez par vous demander : « Qu’est-ce qu’une user story ? ». En résumé, chaque user story suit le modèle « En tant que [rôle], je souhaite [objectif], afin que [avantage] », et toute user story de qualité peut être directement intégrée à 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 qu’un concepteur et un testeur peuvent exploiter. 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 spécification :

• 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 n’est attribué à 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 à le retrouver 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 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 expose clairement l’avantage : 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 : à 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. C’est le travail d’un trimestre condensé en une seule phrase, ce qui en fait une épopée, pas 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.

Le projet d’envergure se décompose en 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 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 poste qui détermine les exigences. Le personnel administratif ne remarque jamais l’assistance 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 est-on hors ligne ? », la réponse est déjà donnée par la nature même du poste : 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 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 un 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 (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 ; cette tâche se comporte donc comme n’importe quelle autre story : elle se voit attribuer 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 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 de la tâche. 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 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 blocages 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 inhérent à ce format. Rédigez votre prochaine série d’histoires à partir 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

Pourriez-vous donner un exemple d’histoire utilisateur ?

« 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. » Cette phrase désigne une personne spécifique, une fonctionnalité telle que la conçoit cette personne, ainsi que la raison pour laquelle il est utile 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), le 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 la fiabilité de la vélocité. Un bug que personne ne parvient à reproduire ne peut pas l’être : il n’y a pas de périmètre à promettre, de sorte qu’une story ne serait 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 le nombre de cinq, cela signifie que le scénario en comprend plusieurs, et les critères vous indiquent où les séparer.

Lectures complémentaires

• L’estimation agile : le guide complet. Vous trouverez ici toutes les informations nécessaires.
• Qu’est-ce qu’une « user story » ? Le format, les trois « C » et la liste de contrôle INVEST qui sous-tendent chacun des exemples ci-dessus.
• Modèle d’histoire utilisateur et critères d’acceptation. Un modèle prêt à copier-coller et un exemple concret, de la rédaction à l’estimation.
• Décomposition des user stories. Que faire des épopées qui se cachent dans les exemples 6 et 16 ?
• Exemples d’estimation agile. La série complémentaire : à quoi ressemble concrètement l’évaluation de ces stories en réunion.