Comment écrire une user story ?

Écrire une user story est un art difficile à maitriser.

Contrairement au formalisme habituel, je vous partage un framework simple pour écrire une user story efficace.

Après la lecture de ce post, vous saurez :

• Quelles sont les fausses vérités sur la user story
• Comment appliquer Mon framework SET pour écrire une user story
• La forme à employer pour écrire une user story réussie.

Petite définition d’une user story

La définition donnée habituellement pour une user story est qu’il s’agit d’une description simple d’une fonctionnalité à développer.

Mon résumé est qu’il s’agit d’une tâche écrite par le product owner à destination de son équipe technique.

Au delà de cette description générale, la user story est toujours accompagnée de “critères d’acceptation”.

Les critères d’acceptation permettent aux développeurs de comprendre les contours technique de la fonctionnalité.

Pourquoi je n’emploie pas le terme de fonctionnalité ?

Je pense que la description d’une fonctionnalité est parfois trop lourde pour être résumé dans une simple user story.

Il est bien évidemment possible qu’une fonctionnalité soit résumé dans une seule user story.

Dans la pratique, bon nombre de fonctionnalités nécessitent plusieurs user stories pour être complètes.

En disant cela, je sais que beaucoup vont me dire que c’est absolument faux. Une user story doit être absolument indépendante.

Une user story n’est pas forcément indépendante

Beaucoup d’organisation suivent le framework INVEST pour écrire leurs user stories.

Le I de INVEST signifie indépendante, ce qui veut dire que chaque user-story doit être indépendante les unes des autres. Ceci afin d’éviter toutes dépendances de planification et de tests.

Je comprends pourquoi quand on débute on à besoin de se rattacher à ce Framework pour essayer de bien faire.

Ceci étant dit, j’aimerais bien toucher deux mots au théoricien qui a pondu cet acronyme et qu’il me montre comment il l’applique dans la pratique.

Voici les 3 principales raisons qui font qu’une user story ne doit pas être absolument indépendante pour être validé.

Raison 1:

Imaginons une user story qui implique le développement d’un outil de recherche à filtres sur un réseau professionnel à l’identique de LinkedIn.

Dans le champ principal, l’utilisateur pourra rechercher une personne par son nom et son prénom.

Dans les filtres avancées, l’utilisateur pourra filtrer des personnes par “Pays”, “Métier”, “Année d’expérience”.

OK. au niveau expérience utilisateur c’est du basique.

En revanche au niveau développement quelque soit la technologie employée, il y a du boulot.

Au niveau front-end, il y a mille questions à se poser ici.

• Où s’intègre la barre de recherche sur le site ? 
• Est ce que les options de filtres sont visibles ou peuvent être affichés en cliquant sur un lien / bouton ?

Au niveau backend, il y en a aussi un tas d’autres :

• Doit-on créer un nouvel endpoint API pour rechercher les personnes dans la base ?
• Quel type de données doit-on retourner (Prénom, nom, photo ? …)
• Dans quel ordre retourne t-on les résultats ? (Chronologique, alphabétique…)
• Quel est le nombre de résultats maximum envoyé par requête ?
• Doit-on faire une pagination pour limiter le temps de chargement ?

Bref, je pourrais continuer encore pendant longtemps. L’idée ici est que pour une simple fonctionnalité, il y a plusieurs paramètres en prendre en compte.

Au minimum, il y a une implémentation backend et frontend. Ces deux implémentations correspondent à 2 expertises différentes.

Du coup, à moins que vous ne travaillez avec un développeur full stack qui est une superstar, vous allez devoir écrire 2 users stories différentes.

Et bien évidemment ces 2 users stories sont dépendantes l’une de l’autre.

Raison 2:

Toujours dans le framework INVEST, le V correspond au mot Valeur
Cela signifie en gros que la réalisation d’une User Story doit rendre un service à l’utilisateur. Elle n’a de sens que si elle apporte une valeur métier. 

Comme on l’a vu dans la raison numéro 1, si je découpe ma fonctionnalité entre une partie backend et une partie frontend, chaque user story ne pourra pas apporter de la valeur indépendamment.
Il faudra attendre que les 2 user stories soient complètes pour apporter de la valeur à l’utilisateur final

Encore une fois cela va à l’encontre de la théorie.
Pour ma part, c’est la seule manière de pouvoir minimiser le temps de développement et d’isoler les problèmes de tests.

Raison 3: 

Si il y a bien une chose avec laquelle je suis d’accord avec le framework INVEST c’est à propos du terme Small (qui correspond à la lettre S).

En effet, chaque user story doit être bien découpée afin d’être livrée au sein d’un seul Sprint.

Si on reprend l’exemple de la fonctionnalité “outil de recherche à filtres”, est-ce que quelque chose vous choque ?

Où s’affiche les résultats de recherche ?

Dans la méthode INVEST, pour que la story soit indépendante , il manque la page de résultat pour compléter la story. 
Sans cette page de résultat, l’outil de recherche est inutile.

Evitez la contradiction

Si vous voulez respecter le principe d’indépendance et de valeur (rendre un service à l’utilisateur), vous allez créer ici une user Story ÉNORME et indigeste.

En plus de la partie frontend et backend de l’outil de recherche et de filtre, vous allez devoir prendre en compte la page de résultats de recherche:

• Où affiche t-on les résultats de recherche ? (nouvelle page ?, iFrame ? )
• Comment affiche t-on les résultats ? (Listes, vignettes…?)
• Combien de résultats par page ? Doit on créer une pagination ?
• Qu’affiche t-on  si il n’y a pas de résultat ?
• Qu’affiche t-on en cas d’erreur ?
• Etc…

Nous pourrions même aller encore plus loin et imaginer ce que peut faire l’utilisateur pour interagir avec la page de résultats.

• Peut-on cliquer sur les résultats ? (nouvel onglet ou même page ?)
• Comment revenir à la page de recherche initiale ?
• Etc…

Vous voyez ce que je veux dire ?

Mon but n’est pas de démonter le framework INVEST, mais dans la pratique certains principes se contredisent.

Une user story peut être rarement courte, valorisable et indépendante à la fois.

Le Framework SET

Dans les lignes précédentes je vous ai expliqué les incohérences du framework invest.
Si vous essayez de respecter tous les principes de ce framework vous allez vous arracher les cheveux.

Afin de vous simplifier la vie, je vous propose ma version allégé d’INVEST, que j’ai modestement rebaptisé SET.

Ce framework reprend 3 des principes de INVEST que j’ai ordonné par ordre d’importance.

Small

Comme pour framework INVEST, le S du framework SET correspond au mot Small.

Selon moi, chaque user story doit être suffisamment courte pour pouvoir être livrée au sein d’un seul Sprint.

Peu importe la durée de votre sprint (1 semaine, 2 ou 3..) veillez à découper votre User Story le plus finement possible.
Mieux vaut en créer deux petites, qu’une seule grande.

De tous les principes, c’est le plus important.

Faites attention à la taille de votre user story.

Estimable

Il est d’usage de dire qu’une user story se place du point de vue de l’utilisateur final du produit.

C’est vrai mais…
Ayez toujours en tête que vous écrivez une user story pour vos développeurs avant tout (jamais pour le client). 

Le client ne lira jamais votre user story, il n’a aucune idée de ce que c’est et s’en fiche.

L’écriture d’une user story du point de vue de l’utilisateur permet seulement de justifier la valeur business ou métier de la fonctionnalité.

En résumé:

Vous faites une user story pour l’utilisateur

Vous écrivez une user story pour les développeurs.

La nuance est importante.

De ce fait, votre user story doit être assez compréhensible pour que votre équipe soit en capacité de l’estimer.

Si vous respectez le principe 1 et que votre user story est suffisamment courte et précise alors vous allez éviter les “corner cases”.

Ceci va vous permettre de simplifier sa compréhension et son estimation lors du grooming.

Au delà de la précision, il va falloir faire attention à la forme.
Je vous explique un peu plus loin dans cette article comment écrire une user story lisible

Testable

Dernier principe important, la testabilité.
Quelque soit la personne qui la teste (de préférence un ingénieur QA), votre user story doit être toujours accompagnée de “critères d’acceptation”.

Sans les critères d’acceptation, il est impossible de valider la story et de la finaliser.

Les critères d’acceptation permettent également de définir les contours techniques et UX de la fonctionnalité afin de ne pas ajouter du code inutile.

Exemple d’une user story SET.

Reprenons encore une fois l’exemple de de la fonctionnalité “outil de recherche à filtres”.

Pour commencer, j’écrirais ma première user story à destination du développeur Front-end.

Titre: Afficher une barre de recherche dans le header.

US: En tant qu’utilisateur du site XXX,
je dois pouvoir rechercher des professionnels de n’importe où sur le site 
afin de les ajouter facilement à mon réseau.

Critères d’acceptation:

Les avantages

Cette user story est courte, voire minimaliste mais suffisamment précise pour être estimée et testée dans un seul sprint.

Nous sommes très loin de la fonctionnalité d’origine mais…

• Grâce au découpage de vos user story vous allez pouvoir démarrer plus vite le développement.
• Cela simplifie le grooming avec vos développeurs et surtout la phase de test.

En effet, si vous rencontrez un bug, il est plus facile d’isoler le problème sur un périmètre restreint.

En parallèle, j’écrirais d’autres user stories qui peuvent débuter dans le même sprint ou le suivant.

2. Implémentation des Endpoint API pour outil de recherche (backend)
3. Affichage de la recherche avancée par filtre (frontend)
4. Affichage de la page de résultats de recherche en mode liste (frontend)
5. Affichage de la page de résultats de recherche en mode vignettes (frontend)
etc….

Ce découpage permet de tester et d’ajuster en temps réel les briques de la fonctionnalité au cas où des choses surviennent en cours de route.

C’est ça l’agilité.

Et la valeur de la user story dans tout ca ?

Où sont donc passé les 3 autres principes du framework INVEST, ceux que j’appelle le VIN.

V -> Valeur

I – > Indépendante

N -> Négociable

Ces 3 principes peuvent bien évidemment s’appliquer à une user story à condition qu’ils ne compromettent pas le Framework SET.

• Si vous ne pouvez pas écrire une user story indépendante sans compromettre sa taille.
• Ou si, vous ne pouvez pas écrire une user story qui à de la valeur immédiate pour l’utilisateur sans compromettre son estimation…

Alors, laissez de côté ces 3 principes au niveau de votre user story et incluez les au niveau du SPRINT.

Je ne vais pas rentrer dans les détails dans cet article, car dans le prochain post j’évoquerais la priorisation du backlog et le sprint planning.

Retenez juste que la valeur que vous apportez à vos utilisateurs / clients est délivrée au niveau du sprint (pas juste au niveau de la user story).

Vous ne mettez jamais une user story seule sur le marché (ou très rarement).

Votre release comprend toutes les users stories que vous avez dans votre sprint.

A vous de définir l’ensemble des users stories qui forment votre sprint et qui peuvent être délivrés et apporter de la valeur aux utilisateurs.

De la même façon, l’indépendance se détermine au niveau du sprint.

Comme en théorie chaque sprint doit amener une nouvelle release utilisateur, alors chaque sprint doit être indépendant les uns des autres.

La forme

Maintenant que vous savez quoi écrire pour votre user story, il s’agit de savoir comment l’écrire.

La majorité des product owners écrivent des users stories en suivant un formalisme qui fait consensus dans le milieu.

La user story

Au niveau de la user story en elle même, on retrouve souvent la syntaxe :
« En tant que … Je veux … Afin de … ».

Cette structure narrative permet de définir le rôle, le besoin et le bénéfice en une seule phrase simple.

Exemple : 

En tant qu’utilisateur du site XXX (RÔLE), 
je veux pouvoir rechercher des professionnels sur le site (BESOIN)
afin de les ajouter facilement à mon réseau (BÉNÉFICE).

Sachez que rien ne vous oblige à suivre ce modèle. L’essentiel est que les développeurs comprennent votre user story comme ça ou autrement.

Pour ma part je n’ai absolument pas d’avis sur la question.

Comme je ne savais pas comment écrire une user story à mes débuts, j’ai copié cette structure narrative pour me faciliter la vie. 

Depuis, comme je m’y suis habitué, j’écris l’essentiel de mes user stories comme ça.

A RETENIR :
Ne vous forcez pas à suivre une structure narrative précise pour écrire votre user story si ca ne colle pas avec votre tâche.

Par exemple, si vous avez une tâche technique à réaliser qui doit vous servir pour écrire une future fonctionnalité, il est ridicule d’utiliser une structure narrative qui se place du point de vue du client.

Les critères d’acceptation :

Là aussi il existe un principe d’écriture des tests d’acceptation que l’on retrouve souvent dans la documentation des user stories.

Ce principe suit la syntaxe Gherkin et se présente sous la forme suivante :

Étant donné que …
Et …
Alors …

Cette structure est traduit de la version anglaise de la syntaxe Gherkin (Given, when, then)

Comme vous avez pu le remarquer plus haut dans l’exemple de la user story sur “l’outil de recherche à filtres”, je n’utilise pas cette syntaxe.

Avant de vous donner la raison, il faut que vous explique l’origine de cette syntaxe.
Je suis sûr que beaucoup d’entres vous l’utilisent sans savoir pourquoi.

C’est quoi le Gherkin ?

En gros, le langage Gherkin est utilisé dans des logiciels d’automatisation de test tels que Cucumber ou Jbehave.

Ces outils sont utilisés par des ingénieurs QA pour automatiser des tests.

En reprenant la syntaxe Gherkin pour écrire vos critères d’acceptation, vous faites gagner du temps à votre ingénieur QA.

En effet, il n’a plus qu’à copier / coller chacun de vos critères pour générer un script dans son outil.

Avouez ! Combien d’entres-vous saviez ça ?

Du coup, maintenant que vous comprenez l’origine de la syntaxe Gherkin, vous pouvez vous douter pourquoi je ne l’utilise pas.

• Primo, les trois-quart des users stories que j’écris sont soumises à des tests manuels.
• Deuxio, mon ingénieur QA n’utilise pas d’outils qui fait appel au langage Gherkin.
• Enfin, je trouve cette syntaxe pénible à écrire et je trouve qu’elle alourdit la description de la user story.

En toute honnêteté, même si j’avais un ingénieur QA qui utilisait cette syntaxe, je lui laisserai écrire ses scripts à part dans son logiciel à partir de mes critères d’acceptation.

Encore, une fois ici, il n’y a pas de règles pour écrire des critères d’acceptation.

La seule règle qui compte est “Est ce que les développeurs les comprennent ? “

Connaissez les personnes qui vont travailler sur votre user story 

Le meilleur conseil que je puisse vous donner pour écrire une user story est de connaître à l’avance la personne qui sera en charge de travailler dessus.

En théorie vous connaissez les membres de votre équipe.

Du coup, vous pouvez déterminer à l’avance qui a l’expertise la plus appropriée pour réaliser les tâches incluent dans la user story.

Si vous savez ça et vous avez l’habitude de travailler avec ce développeur, alors le reste est juste une formalité.

Employez les mots et le ton qui lui correspond le plus.

Oubliez deux minutes le formalisme et mettez-vous à sa place pour imaginer quel ton est le plus approprié pour sa compréhension.

Je ne le répéterai jamais assez, vous écrivez une user story pour un développeur.

Une user story réussie est une story comprise par celui ou celle qui sera en charge de l’accomplir.

Ne compliquez pas les choses

Au final une user story, ce n’est pas compliqué à écrire.

Le plus dur est d’avoir en tête un plan général de la fonctionnalité à développer et de connaître des développeurs qui vont participer à son élaboration.

Une fois que vous avez ça, c’est à vous de découper vos users stories afin qu’elles respectent les 3 principes SET :

• Small
• Estimable
• Testable

En fonction du logiciel d’écriture que vous utilisez, vous pouvez regrouper toutes vos users stories qui ont le même thème dans une épic.

Faites appel à votre bon sens et connaissez les développeurs avec qui vous travaillez.

Si vous avez l’impression que vos users stories ne sont pas comprises lors de vos sessions de grooming, il est temps de vous adapter (et de lire ceci).

Pour le reste c’est à vous de voir si vous voulez suivre les Frameworks Scrum habituels.

Ne soyez pas intimidé par le fait de sortir des sentiers battus. En théorie personne ne vous jugera si votre méthode fonctionne.

Si vous travaillez au côté d’autres product owners qui vous dictent leur méthodes, assurez-vous de ne pas copier bêtement quelque chose qui ne fonctionne pas parfaitement.

Souvenez-vous également que la majorité des conseils que vous trouverez sur internet pour écrire une user story ne sont pas rédigés par des product owners.

Pour écrire une bonne user story, rien ne vaut la pratique.