Qu'est-ce qu'une « user story » ?

Une « user story » est une description concise et rédigée en langage clair d’un changement, présentée du point de vue de la personne qui en bénéficie : « En tant que client fidèle, je souhaite me connecter avec mon adresse e-mail afin de pouvoir consulter l’historique de mes commandes. » Il ne s’agit délibérément pas d’un cahier des charges. La fiche contient la promesse d’une discussion, et les détails sont précisés lorsque l’équipe affine l’histoire, rédige ses critères d’acceptation et en évalue l’ampleur.

Tout le reste de ce guide s’articule autour des stories. Ce sont elles que le planning poker permet d’évaluer, auxquelles les story points sont associés, et qui sont divisées lorsque l’estimation ne parvient pas à converger. Une équipe qui rédige de mauvaises stories fera de mauvaises estimations, quelle que soit la qualité de la conduite de la session, car c’est au niveau des données d’entrée que le problème commence.

Le format : rôle, objectif, avantage

Cette forme classique remonte à Connextra, une équipe XP londonienne, vers 2001 :

En tant que [rôle], je souhaite [objectif], afin que [avantage].

Il y a trois emplacements, et chacun remplit une fonction.

• Le rôle désigne la personne à qui s’adresse la valeur. « En tant qu’utilisateur » est l’erreur la plus courante dans ce format : une histoire qui pourrait concerner n’importe qui est une histoire pour laquelle personne n’a réellement été consulté. Nommez la personne en question : le client fidèle, le développeur d’intégration.
• L’objectif correspond à la fonctionnalité telle que la conçoit l’utilisateur ; il décrit ce que la personne fait plutôt que la manière dont le système est conçu. « Je souhaite réinitialiser mon mot de passe » est un objectif. « Je souhaite disposer d’un microservice de réinitialisation de mot de passe » est une décision de conception qui reprend cette formulation.
• L’intérêt est la clause que les équipes écartent en premier, et c’est celle-ci qui justifie la place de la carte dans le backlog. La partie « afin que » constitue l’argument justifiant l’intégration de cette tâche au planning. Si personne ne peut la mener à bien, le travail n’a pas de raison d’être, et c’est en rédigeant cette clause que vous vous en rendez compte avant le début du sprint, plutôt qu’après.

Carte, conversation, confirmation

Ron Jeffries a résumé le fonctionnement des récits en trois « C », dont l’ordre est important.

La carte est un support symbolique — une ou deux phrases, volontairement succinctes. Sa taille est une caractéristique essentielle : elle ne peut physiquement pas contenir l’intégralité d’une exigence, ce qui oblige à passer à la prochaine étape « C ».

C’est au cours de la conversation que l’exigence prend réellement forme. L’équipe et le Product Owner discutent en détail du cas d’utilisation lors du raffinement du backlog : les cas limites et ce qui est explicitement hors du périmètre. Les équipes qui sautent cette étape et considèrent la fiche comme l’exigence se retrouvent dans une situation désavantageuse à double titre : un document trop succinct pour servir de base de développement, et l’absence de discussion sous prétexte que « c’est déjà écrit ».

La confirmation correspond aux critères d’acceptation : il s’agit des conditions de réussite ou d’échec qui permettent de déterminer si le travail achevé répond bien à ce qui a été convenu lors des échanges. Le chapitre consacré au modèle d’histoire utilisateur présente les deux formats qui conviennent, tandis que le chapitre consacré aux critères d’acceptation aborde en détail la manière de les rédiger.

La liste de contrôle INVEST

La liste de contrôle de Bill Wake datant de 2003 reste le moyen le plus rapide de vérifier si une histoire est prête à être développée. Une bonne histoire, c’est :

• Indépendant — peut être planifié séparément, sans que cela implique d’inclure trois autres tâches dans le sprint.
• Négociable — la fiche invite à la discussion ; le champ d’application peut encore évoluer. Une histoire dont chaque détail est figé n’est qu’une exigence déguisée en récit.
• Pertinent — la clause introduite par « afin que » résiste à un « pourquoi ? » sincère.
• Évaluable — l’équipe peut lui attribuer une valeur chiffrée. Une story dont personne ne peut estimer la taille comporte une inconnue ; effectuez un spike pour la déterminer.
• Petit — tient dans un sprint sans problème. Si ce n’est pas le cas, divisez-le.
• Vérifiable — vous pouvez définir des critères d’acceptation qui peuvent être validés ou rejetés. « La page semble plus rapide » entraîne un échec ; « les résultats s’affichent en moins d’une seconde » entraîne une réussite.

C’est au niveau des « estimables » et des « petites » que les récits rejoignent le reste de ce guide. Un écart important dans les votes lors du « planning poker » est généralement le signe d’un échec de la phase d’INVEST qui se manifeste tardivement : le récit était négociable d’une manière que personne n’avait envisagée, ou trop vaste pour que quiconque puisse en avoir une vue d’ensemble.

Ce qu’une « user story » n’est pas

Ce n’est pas une tâche. Une histoire correspond à un résultat concret pour l’utilisateur ; une tâche est une étape que l’équipe doit franchir pour y parvenir. « Se connecter avec son adresse e-mail » est une histoire. « Configurer le stockage des sessions » est l’une de ses tâches. Le chapitre consacré à la distinction entre épopée, histoire et tâche explique cette hiérarchie et pourquoi les points ne doivent être attribués qu’au niveau de l’histoire.

Ce n’est pas un document d’exigences. Une exigence doit être définie de manière exhaustive avant le début des travaux. Une story doit être suffisante pour lancer la discussion, sans plus. Juger les stories à l’aune des critères d’exigences (« c’est trop vague ! ») revient à passer à côté de l’esprit même de la conception : ce flou est une marge de manœuvre réservée au jugement de l’équipe.

Ce n’est pas une promesse de mise en œuvre. L’histoire définit le résultat ; c’est à l’équipe de décider de la manière de s’y prendre. Lorsqu’une histoire est présentée avec une solution déjà prédéterminée, la partie négociable du modèle INVEST a déjà disparu.

Quand les « user stories » ne sont pas l’outil adéquat

Ce format a ses limites, et prétendre le contraire nuit à la crédibilité auprès des personnes chargées de rédiger les phrases les plus délicates. Dans certains cas, le pronom « work » n’apparaît pas dans la phrase :

• Travail en profondeur sur la plateforme. « En tant que développeur, je souhaite mettre à jour le framework, afin que celui-ci soit mis à jour » : cela n’ajoute rien de plus que ce qui figure déjà dans le titre du ticket. Formulez-le comme un simple travail technique avec un résultat concret : ce qui ne fonctionnera plus ou sera ralenti si cela n’est pas fait, et ce qui sera facilité une fois que ce sera fait.
• Bugs dont la cause est connue. Un rapport de défaut (comportement attendu, comportement réel, étapes pour reproduire le problème) constitue un format plus approprié qu’une story adaptée a posteriori. Le chapitre consacré aux points de story explique dans quels cas les bugs sont attribués des points.
• Les « pics de recherche ». Un « pic » correspond à une question associée à un délai défini, et son résultat est la connaissance. Le fait de le contraindre à suivre le schéma « rôle-objectif-bénéfice » occulte l’essentiel : ce que l’équipe doit apprendre.
• Travail de mise en conformité. Vous ne pouvez pas négocier le périmètre d’intervention avec une autorité de régulation. Une exigence est une exigence ; consignez-la comme telle.

Ce qui est commun à tous ces exemples, c’est la rigueur, et non la forme de la phrase : une raison clairement énoncée expliquant pourquoi ce travail est important, et une définition vérifiable de ce que signifie « terminé ». Si vous respectez ces deux éléments, le format aura rempli son rôle, même dans les cas où il ne s’applique pas.

Quand les récits rencontrent l’estimation

Une story constitue l’unité d’estimation. Une fois rédigée, elle suit le parcours décrit dans ce guide : l’équipe en discute, l’évalue en points de story à l’aide du planning poker, vérifie sa conformité avec la définition de « prêt » et la divise si le vote ne parvient pas à aboutir à un consensus. Une story bien formulée accélère chacune de ces étapes, ce qui constitue la raison pratique pour laquelle il est important de veiller à son format.

Pour découvrir comment ce format s’applique, le chapitre consacré aux exemples d’histoires utilisateur présente seize histoires annotées, qu’elles soient réussies ou non. Pour rédiger la vôtre, commencez par le modèle.

Foire aux questions

Qu’est-ce qu’une « user story » ?

Une « user story » est une description concise et rédigée en langage clair d’un changement, présentée du point de vue de la personne qui en bénéficie : « En tant que client fidèle, je souhaite me connecter avec mon adresse e-mail afin de pouvoir consulter l’historique de mes commandes. » Il ne s’agit délibérément pas d’un cahier des charges. La fiche sert de point de départ à une discussion, et les détails sont précisés lorsque l’équipe affine et évalue l’ampleur du travail.

En quoi consiste le format « user story » ?

Le format classique est « rôle-objectif-avantage » : « En tant que [rôle], je souhaite [objectif], afin que [avantage]. » Le rôle désigne la personne qui bénéficie de la valeur, l’objectif définit la capacité en termes compréhensibles pour l’utilisateur, et l’avantage constitue l’argument justifiant la planification du travail. Si personne ne peut compléter la clause « afin que », la story n’a pas sa place dans le backlog.

Quels sont les trois « C » des user stories ?

Carte, discussion, confirmation. La carte sert de rappel ; elle est délibérément trop succincte pour contenir l’exigence dans son intégralité. C’est lors de la discussion que l’exigence prend réellement vie, au fil des itérations menées avec l’équipe. La confirmation correspond aux critères d’acceptation qui déterminent si le travail achevé répond ou non à ce qui a été convenu, en indiquant s’il est « réussi » ou « échoué ».

Que signifie l’acronyme INVEST ?

Indépendante, négociable, utile, évaluable, de petite envergure, testable. Il s’agit de la liste de contrôle établie par Bill Wake pour déterminer si une story est prête à être traitée. Dans la pratique, ce sont les trois derniers critères qui ont le plus de poids : une story que l’équipe ne peut pas estimer, qui ne tient pas dans un sprint ou dont aucune vérification ne permet de confirmer la validité n’est pas encore prête.

Dans quels cas ne faut-il pas utiliser les user stories ?

Lorsque le format apporte davantage de formalités que de clarté. Les travaux approfondis sur la plateforme, les corrections de bogues dont la cause est connue, les exigences de conformité et les projets de recherche ponctuels trouvent tous mieux leur place dans leur format d’origine. Conservez la clause de bénéfice et les critères d’acceptation ; évitez la formule « En tant que développeur, je souhaite » lorsqu’il n’y a pas d’utilisateur dans la phrase.

Lectures complémentaires

• L’estimation agile : le guide complet — la plateforme de référence pour tout ce qui concerne ce sujet.
• Exemples d’histoires utilisateur — seize histoires commentées, y compris celles qui échouent et les raisons de cet échec.
• Modèle d’histoire utilisateur et critères d’acceptation — le modèle, ses variantes et un exemple concret allant jusqu’à l’estimation.
• Épopée vs histoire vs tâche — où se situe l’histoire dans la hiérarchie, et quel niveau est mis en avant.
• Décomposition des user stories — que faire lorsqu’une user story ne satisfait pas au « petit test » ?