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

Une « user story » est une description concise et rédigée en langage clair d’un changement, raconté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 les problèmes commencent.

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 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 : elle ne peut physiquement pas contenir l’intégralité d’une exigence, ce qui oblige à passer à la prochaine étape « C ».

C’est dans la conversation que réside véritablement l’exigence. L’équipe et le Product Owner discutent en détail du cas d’utilisation lors du raffinage 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 doublement défavorable : 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 : les 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 explique en détail comment 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épendante : peut être planifiée seule, sans entraîner 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 rédiger des critères d’acceptation qui sont soit satisfaits, soit non satisfaits. « La page semble plus rapide » ne satisfait pas ce critère ; « les résultats s’affichent en moins d’une seconde » le satisfait.

Les critères « estimable » et « petit » sont les points de rencontre entre les récits et 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 apparaît 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 story apporte quelque chose de concret à 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 story. « 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 figurer qu’au niveau de l’histoire.

Ce n’est pas un document d’exigences. Une exigence doit être complète 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 applicables aux 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éterminer la manière de s’y prendre. Lorsqu’une histoire est présentée avec une solution déjà définie, 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 de ceux qui doivent 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 » n’apporte rien de plus que ce que le titre du ticket indiquait déjà. 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 réduire à une formulation « 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 avec une autorité de régulation. Une exigence est une exigence ; consignez-la comme telle.

Ce qui est commun à tous ces cas, c’est la rigueur, et non la forme de la phrase : une raison clairement exposé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 à converger. 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 est mis en pratique, 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 le bénéfice constitue l’argument justifiant la planification du travail. Si personne ne peut compléter la clause « afin que », la story n’a aucune raison de figurer 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 au cours de la discussion que l’exigence prend réellement forme, au fil des itérations avec l’équipe. La confirmation correspond aux critères d’acceptation qui déterminent, par « réussi » ou « échoué », si le travail achevé répond bien à ce qui a été convenu.

Que signifie l’acronyme INVEST ?

Indépendante, négociable, utile, évaluable, de petite envergure, testable. Il s’agit de la liste de contrôle de Bill Wake permettant de déterminer si une story est prête à être traitée. Dans la pratique, ce sont les trois derniers critères qui pèsent le plus : une story que l’équipe ne peut pas estimer, qui ne s’inscrit pas dans un sprint ou dont la validité ne peut être confirmée par aucun test n’est pas encore prête.

Dans quels cas ne faut-il pas recourir aux 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 pics de recherche 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. C’est ici que vous trouverez toutes les informations nécessaires.
• Exemples d’histoires utilisateur : seize histoires commentées, y compris celles qui échouent et les raisons de cet échec.
• Modèle de récit utilisateur et critères d’acceptation : le modèle, ses variantes et un exemple concret allant jusqu’à l’estimation.
• Épopée, histoire et 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 » ?