Quel PO ne se souvient pas de ce moment, après avoir terminé un super atelier de User Story Mapping. Ce moment où vous vous sentiez très fier du travail accompli avec vos parties prenantes et votre Scrum team. Oui ce moment, juste après vous être retrouvé seul devant ce graaaaannnnnd tableau rempli de Post-it ?
Ou encore de cet autre moment, juste après ce nouvel atelier de récupération des besoins que vous a conseillé votre merveilleux Scrum Master et que vous avez réalisé avec brio avec vos équipes métiers ?
Viens ensuite cette petite voix qui vous dit :
« Bien ! Maintenant, il faudra rédiger des US pour tout ces Post-it, mais quelle galère. Note à moi même, réaliser dorénavant cet atelier directement à travers un outil informatique.
Ah non, on efface, j’ai déjà essayé. L’ambiance n’est pas du tout la même.
Re-note à moi même, le Post-it, c’est la vie. Ah mais au fait, maintenant que j’y pense, comment rédige t-on réellement une bonne User `Story ? »
« C’est quoi cette histoire de petite voix » vous me dites ? Suis-je donc le seul à l’entendre cette petite voix intérieure ?
N’ayez crainte ! Dans cette article, nous ne parlerons bel et bien que de User Story, et non de ma petite voix qui semble vous faire soudainement douter de moi.
Pour ce faire, commençons par poser les bases, à savoir : qu’est-ce que c’est une User Story ?
La User Story, parlons-en !
Une « User Story » , ou « Récit Utilisateur » en français et communément appelé « US » est une phrase. Oui je sais, cela ne nous avance guère pour le moment. Alors pour compléter mes propos, je vous dirais qu’une User Story est écrite dans un langage de préférence non technique et elle doit être compréhensible pour tout un chacun. Elle doit décrire le plus simplement possible une action, et elle est avant tout centrée utilisateur.
La User Story, c’est une base qui vous permet de discuter valeur et impact pour votre utilisateur. Lorsqu’elle est correctement écrite, elle permet à l’équipe de comprendre à la fois, quel est le travail à réaliser, pourquoi ils vont réaliser ce travail et surtout quel est l’impact pour l’utilisateur final. Je dirais même que la User Story doit vous permettre d’aligner toute votre équipe afin d’avancer dans une même direction, avec la même vision.
Un template couramment utilisé pour l’écriture d’une User Story est le suivant :
| English | Français |
|---|---|
| As a [persona], | En tant que [persona], |
| I want to [the goal], | Je veux que [le but], |
| In order to [the reason]. | Afin de [la raison]. |
PERSONA
Le persona est une représentation fictive de la cible que vous avez identifié et qui souhaite réaliser l’action de votre User Story. Il est préférable d’écrire une US par persona. C’est notamment le cas lorsque vous avez identifié plusieurs personas pour une même User Story.
THE GOAL
Le but représente l’objectif à atteindre de votre persona. Il faut bien faire attention à ne pas parler fonctionnalités ou composants logiciel, mais bien de l’action que souhaite réaliser votre persona.
THE REASON
La raison permet d’apporter de la clarté à votre US. Souvent elle définit la valeur ou le risque que va apporter votre User Story à votre persona.
On pense souvent qu’un persona dans une US ne peut être qu’un être vivant, mais ne vous y trompez pas. On peut réaliser des US pour toutes sortes de personas, un serveur informatique, un meuble, une pomme-liane et même un ascenseur.
Vous êtes perplexe ? Voici un exemple :
| En tant qu‘ascenseur, Je veux connaitre la liste des étages autorisés de mon utilisateur, Afin de n’afficher uniquement les étages autorisés sur mon écran tactile. |
Théoriquement, une US bien rédigée est amplement suffisante pour commencer à délivrer de la valeur. Mais dans la pratique, je dois avouer que c’est un peu plus complexe. Je vais vous expliquer pourquoi je pense qu’il est nécessaire d’en affiner les contours, et ce qui définit pour moi, ce qu’est une bonne User Story, notamment lorsque l’on travaille dans l’IT.
N’hésitez pas à me dire ce que vous en pensez. Pour vous, quel type de persona peut être considéré pour l’écriture d’une US ? De même, quel est le template que vous utilisez ?
Alors comment faire pour rédiger une bonne User Story ?
Au moment de l’écriture de cet article, je travaille en tant que consultant Product Owner dans l’IT avec des équipes de développement informatique. Certaines informations que je vais vous donner seront liées à ce domaine, mais je ne pense pas que la méthode différera énormément pour d’autres domaines.
Rentrons dans le vif du sujet. Il n’y a pas de méthode miracle pour écrire une bonne User Story.
En revanche, une bonne User Story doit obligatoirement être co-construite avec votre équipe. C’est le seul moyen d’embarquer chaque membre dans une bonne dynamique. En créant une discussion constructive, c’est ainsi que vous allez élaborer la valeur et l’impact que vous voulez provoquer auprès de votre utilisateur final.
Une bonne User Story se doit de correspondre au framework « INVEST » de Bill Wake. Pour rappel, les lettres de cet acronyme correspondent à :
I : Independent
N : Negotiable
V : Valuable
E : Estimable
S : Small
T : Testable
INDEPENDENT
Dans la mesure du possible, il faut éviter toutes dépendances entre vos User Story, surtout pour un même sprint. Chaque dépendance augmentera entre autre la difficulté pour la priorisation des items de votre backlog. Mais aussi la planification et l’exécution des tests lorsque votre US sera terminée.
NEGOTIABLE
`Les détails de votre User Story doivent être négociables en vue de son intégration dans un sprint.
VALUABLE
Une User Story doit être au service de votre utilisateur final et lui apporter de la valeur.
ESTIMABLE
Il est difficile d’estimer une User Story que l’on ne comprend pas. Votre Scrum team doit être capable d’estimer l’US, et cela même en « no estimate » . Si elle ne le peut pas, souvent il faut revoir l’étape des négociations car votre US manque de clarté.
SMALL
Chaque User Story doit être, dans la mesure du possible, suffisamment petite pour intégrer un sprint. Cela permettra d’ailleurs que votre US soit réalisée et testée rapidement.
TESTABLE
Une User Story doit toujours être testable. Une US que l’on ne peut tester, ne peut pas être validée.
Il ne faut pas oublier que chaque équipe avance à son propre rythme afin de trouver le bon équilibre dans le travail d’écriture de leurs US. Des équipes plutôt juniors auront besoin de beaucoup plus affiner les contours de la User Story. Contrairement aux équipes plus séniors et matures, qui en auront beaucoup moins besoin.
« Tu nous parles beaucoup d’affinage et de contours de la User Story mais dans la pratique, qu’est-ce que c’est et comment on le réalise ? » Le retour de la petite voix.
Alors pour répondre simplement, il s’agit de tout le travail que vous allez effectuer autour de cette User Story. « NEGOCIABLE » on a dit. Cela vous permettra d’être certain que toutes les personnes concernées, aient réellement la même compréhension que vous, (et la je vais me répéter), du travail à réaliser, pourquoi ils vont réaliser ce travail et surtout quel est l’impact pour l’utilisateur final.
On pourrait le résumer ainsi : faire disparaitre les incertitudes afin de s’ouvrir à un monde de certitudes.
Et quoi de mieux qu’un template afin de réaliser tout ce travail d’affinage ?
Proposition de template
Le template que je vais vous proposer est plutôt classique et je l’utilise souvent pour rédiger mes US. Si vous souhaitez l’utiliser, n’hésitez pas à l’adapter à votre besoin et votre contexte.
| TITRE |
| USER STORY |
| (facultatif) CONTEXTE |
| (facultatif) INFORMATIONS COMPLÉMENTAIRES / RÈGLES |
| CRITÈRES D’ACCEPTATION |
TITRE
Ajouter un titre à vos US ! Il permettra surtout d’en simplifier la lecture. Un backlog rempli de « As a […], I want to […], In order to […]. » est extrêmement difficile à parcourir. Un simple titre, résumant la fonctionnalité voulue, vous permettra à vous ainsi qu’à votre équipe de mieux naviguer au sein du backlog. Une bonne pratique est de commencer votre titre par un verbe d’action. Cela permettra aussi qu’il soit plus rapidement compréhensible.
CONTEXTE
Le contexte permet de rappeler pourquoi la User Story a été rédigée. Et je dois avouer qu’après avoir dé-priorisé puis re-priorisé beaucoup plus tard certaines US, il est toujours bon de se souvenir dans quel contexte ces dernières avaient pris place.
INFORMATIONS COMPLÉMENTAIRES / RÈGLES
J’ajoute dans cette rubrique toutes les informations utiles à la bonne exécution de la User Story. Des règles de gestion, des pièces jointes avec notamment des wireframes, des maquettes ou encore un parcours utilisateur. On y retrouve aussi les informations liées aux bases de données et aux API. C’est ici que l’on note vraiment tous les entrants et sortants liés à la User Story.
CRITÈRES D’ACCEPTATION
Les critères d’acceptation permettent de définir l’accord qui sera passé entre vous et le reste de votre équipe. Ils permettent de valider le moment où le travail réalisé par l’équipe sera considéré comme terminé.
Personnellement, j’aime utiliser le langage Gherkin pour la rédaction des critères d’acceptation. Ce langage permet notamment d’appuyer la démarche du développement piloté par les tests (TDD). Sa structuration permet de couvrir correctement l’ensemble des cas d’usages de la User Story. Et si vous n’êtes pas familier avec le langage Gherkin, vous pouvez rédiger vos critères comme vous le souhaitez, mais je vous invites fortement à l’utiliser.
Une bonne pratique lors de la rédaction de vos critères d’acceptation est de toujours penser et rédiger les cas d’erreurs avant ceux de succès. Cela vous permettra d’être sûr que vous avez couvert correctement votre User Story.
Voici un exemple du template que j’ai complété avec notre précédente User Story une fois affinée :
| US XXXXX |
|---|
| [Ascenseur] Afficher les étages autorisés sur l’écran tactile |
| En tant qu‘ascenseur, Je veux connaitre la liste des étages autorisés de mon utilisateur, Afin de n’afficher uniquement les étages autorisés sur mon écran tactile. |
| CONTEXTE L’entreprise […] souhaite rendre invisible certains étages de ses bâtiments à toutes personnes non habilitées, notamment pour rendre plus difficile aux visiteurs l’identifications des étages où sont réalisés la R&D. |
| INFORMATIONS COMPLÉMENTAIRES / RÈGLES Wireframe – affichage des étages Maquette message erreur yyyyy Parcours utilisateur – affichage des étages API – serveur xxxxxxx:xxxx / clé xxxxxxxxxxxxxxxxxxxx Serveur d’authentification – xxxxxxxxxx.xxxx / clé xxxxxxxxxxxxxxxxx […] |
| CRITÈRES D’ACCEPTATION 1. Affichage par défaut (GIVEN) Étant donné que l’écran est allumé (WHEN) Lorsque aucun utilisateur ne s’est identifié (THEN) Alors l’écran tactile n’affiche que les étages autorisés aux visiteurs […] 3. Utilisateur identifié et inconnu (GIVEN) Étant donné qu’un utilisateur s’est identifié (AND) Et que l’utilisateur n’a pas pu être reconnu (WHEN) Lorsque l’écran tactile affiche les étages (THEN) Alors un message d’erreur yyyyy est affiché (AND) Et l’écran tactile n’affiche que les étages autorisés aux visiteurs 4. Utilisateur identifié et reconnu (GIVEN) Étant donné qu’un utilisateur s’est identifié (AND) Et que l’utilisateur a été reconnu par le système (AND) Et que l’utilisateur à des autorisation pour des étages autres que ceux des visiteurs (WHEN) Lorsque l’écran tactile affiche les étages (THEN) Alors l’écran tactile affiche les étages autorisés aux visiteurs (AND) Et l’écran tactile affiche les étages autorisés de l’utilisateur […] |
En conclusion
Il n’y a pas nécessairement de façon meilleure qu’une autre pour rédiger une bonne User Story. L’important est de vous approprier correctement votre produit. Vous devez toujours creuser le besoin dans un premier temps et non apporter une solution et ce même si vous avez déjà une idée de comment résoudre le problème.
C’est en discutant avec toute votre équipe et chacune des parties prenante, tout en mettant vos utilisateurs au centre de vos réflexions, que vous pourrez apporter réellement de la valeur et de l’impact.
Il reste trois axes que je ne traite pas dans cet article. Il s’agit des estimations de valeur business, de la valeur de complexité et des KPI. Ils font parti de mon template dans sa version la plus complète, et je vous les présenterai dans un prochain article.
Un produit, est une chose vivante que l’on découvre au fil du temps. Alors expérimentez, trouvez votre façon d’affiner vos User Story afin que vous puissiez définir que vous avez rédigé une bonne User Story.
Enfin, n’hésitez pas à me dire et à partager comment vous faites, vous, pour rédiger une bonne User Story.
Agilement vôtre,
Transparence, Inspection, Adaptation,
Jonathan
[…] Éviter les listes à rallonge et n’écrivez que ce qui fait sens. Oubliez tout ce qui définit qu’une US doit avoir un titre, une description, des critères d’acceptation et j’en passe. Cela relève du bon sens. Il est préférable de travailler le template utilisé pour rédiger vos US que de le spécifier inutilement dans une DOR. J’ai d’ailleurs écrit un article sur le sujet si vous avez un peu de temps pour une petite lecture : La User Story : Comment bien la rédiger ? […]