User stories : bien les rédiger

Dans cet article, nous allons voir comment bien créer ses user stories afin d’optimiser au mieux la partie fonctionnelle. Si la base autour des user stories est souvent comprise, elle est souvent source d’un grand nombre de problèmes et d’incompréhensions.

Vous pouvez regarder la vidéo de la minute agile sur comment bien rédiger vos user stories :

Définition simple des user stories

Une user story est une demande fonctionnelle basée sur l’un ou les utilisateurs clés du produit qui va rajouter de la valeur business au produit. Elle sera écrite dans un langage naturel compris par l’ensemble des acteurs du projet ou liés à celui-ci.

Pour ses user stories, d’où part-on ?

Avoir défini ses personae

Avant même d’écrire ses user stories, il faut bien comprendre qu’il est indispensable d’avoir en amont des personae (soit nos utilisateurs types).

Voir article : Bien écrire son persona dans un projet agile

User journey et story-mapping

A partir de ces personae, vous pouvez même vous aider d’un customer journey voire d’un story mapping pour avoir une meilleure vision pour écrire vos user stories.

Voir les articles pour en savoir plus sur ces pratiques :
Compléter son projet Agile avec un user Journey !
Bien comprendre la création d’un story-mapping

A partir de ces éléments, vous avez normalement une bonne préparation pour créer des user stories de qualité.

Pour nos user stories, partir de demandes bien définies

Il est important de partir de demandes qui sont dites SMART afin d’avoir de bonnes bases pour écrire nos user stories. Si on écrit en général nos user stories à partir du story mapping en début de projet, il est aussi conseillé de partir de demandes qui respectent les 5 règles du SMART.

Article : Créer ses user-stories à partir de demandes SMART

Définissons ce que seront nos user stories

Maintenant que nous avons toutes les bases pour faire de bonnes user stories, nous allons voir comment on va définir ce qu’est une bonne user story.

Le titre (ou résumé)

La base de la user story, c’est de commencer par décrire une demande fonctionnelle à partir d’un utilisateur clé (un personna) tout en écrivant avec un langage naturel qui permet à toute personne de comprendre la demande :

demande fonctionnelle classique : « le client doit pouvoir ajouter un produit dans son panier pour l’acheter »
le titre de la user story : « En tant que client, je souhaite pouvoir ajouter un produit dans mon panier afin de pouvoir l’acheter ».

On suit en fait un format stricte pour que toutes les user stories suivent les mêmes règles ; voici le format à respecter :

En tant que [persona], je souhaite [souhait] afin de [but]
As a <persona>, I want <goal/desire> so that <benefit>

Si on fait des demandes fonctionnelles de différentes façons, on se retrouve souvent avec un backlog compliqué à relire ; il est beaucoup plus facile et agréable de travailler avec un minimum de rigueur mélangé avec un minimum de souplesse.

Autres pratiques existantes sur les user stories

Si la pratique fournit ci-dessus est de loin la plus populaire sachez qu’il existe d’autres formats de user stories comme ceux que nous allons voir tout de suite. Si l’un vous parait plus adapté à vos besoins, n’hésitez pas à utiliser un de ces formats légèrement différents.

Le but n’est plus obligatoire

Mike Cohn a suggéré de rendre optionnel la partie « afin de [but] »car dans certains cas, l’explication semblait plus complexifier la phrase que d’apporter réellement de la valeur.

Faire de la feature injection

Chris Matt propose des user stories avec du feature injection qui permet de mettre en premier la valeur recherchée. C’est un concept intéressant à connaitre.

Afin de [but] en tant que [persona], je souhaite [souhait]
In order to <receive benefit> as a <role>, I want 
<goal/desire>

Se baser sur le Five Ws

Technique très peu connue mais qui apporte également des éléments intéressants est la user story basée sur le five Ws (what, who, where, when, why) ; je ne connais pas le nom français de ce concept donc je vais l’appeler les 5 questions.

En tant que [qui] [quand] [où], je [souhait] parce que 
[pourquoi]
As <who> <when> <where>, I <what> because <why>.

Je ne suis pas trop fan particulièrement de cette méthode car je la trouve un peu trop longue ; cependant, elle existe donc si elle vous parait plus adéquate, vous pouvez sans soucis l’utiliser.

Persona ou rôle

Si l’utilisation du persona s’est popularisé avec le template proposé par Rachel Davies, vous pourriez également utiliser les rôles de ces personae pour le faire.

Il n’est d’ailleurs pas rare de voir quelqu’un utiliser le rôle du persona plutôt que le nom du persona lui même. Je dirais même que c’est devenu le cas le plus populaire en France.

Par exemple si mon persona est : « Rachelle, 41 ans cliente », on mettrait plutôt « En tant que cliente, je souhaite pouvoir ajouter un produit dans mon panier afin de pouvoir l’acheter ».

Si vous préférez mettre le nom du persona, il faudra alors impérativement afficher vos personae dans votre management visuel mais pour les utilisateurs de logiciels tels que Jira, ils devront s’habituer aux personae (ce qui prendra un peu de temps).

Basé sur l’action

Capital One en 2004 a préféré utiliser « l’action avec le système » à la place du « souhait » mais cela reste une subtilité.

En tant que [persona], je peux [action] afin de [but]
As a <persona>, I can <action> so that <benefit>

Voici un exemple de cette subtilité par rapport à la user story exemple qu’on utilise depuis le début de cet article :

Classique : « En tant que client, je souhaite pouvoir ajouter un produit dans mon panier afin de pouvoir l’acheter ».

Basé sur l’action : « En tant que client, je peux cliquer sur le bouton ajouter au panier sur la page produit afin de pouvoir l’acheter ».

Comme vous le voyez c’est subtil mais certains préfèrent travailler sur l’action que le souhait de l’utilisateur.

Le contenu général de nos user stories

Pour commencer, chaque projet aura sa propre façon de créer ses user stories. Le plus important c’est de définir le format de user stories qui convienne au mieux à l’ensemble de l’équipe.

Comprenez bien qu’une user story n’est pas juste un « En tant que [persona], je souhaite [souhait]… » ; ceci est le résumé formaté qui permet d’avoir une vision rapide de la demande mais celle-ci doit évidement être détaillée pour qu’elle réponde à 100% aux besoins des développeurs pour pouvoir la réaliser sans risquer de dévier du besoin exprimé.

Attention pour ceux qui ne sont pas encore agile, l’agilité n’est pas allergique à la documentation, mais juste que chaque user story doit contenir le minimum pour être développable avec un maximum de qualité fonctionnelle et on fera d’éventuelles autres documentations après le développement (doc technique, utilisateur…). Dans le monde agile, on refuse juste d’avoir une documentation de 300 pages avant même de développer le produit. Je vous laisse voir les principes de l’agilité pour mieux comprendre les pourquoi.

Format existant

Pour vous aider, vous pouvez regarder des formats existants qui sont assez efficaces sur lesquels vous pouvez vous baser. Voici un exemple que j’avais proposé qui est très intéressant :

Article : Un format de user-story très efficace : le story A4

N’hésitez pas la première fois à utiliser ce type de format existant et de l’adapter au fur et à mesure. La première fois qu’on lance un projet, il n’est jamais évident de définir un format concret de user story.

Pour définir le format idéal des user stories pour l’ensemble de l’équipe, je vous conseille de faire l’atelier du definition of done (et de ready) qui définira les différents critères de qualité dont le contenu obligatoire de chaque user story.

Article : Faire la Definition of Done des user-story

Par exemple une user story pourra contenir : un description, des critères d’acceptations, des tests d’acceptance, un résumé simple, des règles de gestion. C’est à l’équipe de définir le format qui leur parait idéal pour bien travailler. Il n’y a pas de bonnes réponses sur ce sujet ; le meilleur format de user story est celui qui correspond le mieux à l’équipe à l’instant T.

Des critères de qualités pour créer mes user stories ?

En effet, il existe de plus en plus de critères qui définissent la qualité attendue par une user story. Aujourd’hui le plus connu est celui de l’INVEST qui est des fois mal compris surtout pour la partie I (Indépendante). Je vous laisse aller voir l’article qui en parle :

Article : Qu’est-ce une user story INVEST ?

En respectant toutes ces règles vous devriez être calé pour la création de user stories.

Exemple de comment créer ses user stories

Quoi de mieux qu’un exemple concret pour bien comprendre ?

J’avais créé un persona lors d’un précédent article représentant un client d’un site ecommerce (exemple que j’adore car il est facile à comprendre pour tout le monde).

A partir de ce persona, j’avais justement créé un customer journey du parcours utilisateur de mon client sur mon site ecommerce :

Je vais utiliser mon logiciel (Jira par exemple) pour créer mon persona tout en me basant sur le format story A4 :

Titre : « Pouvoir ajouter un produit dans mon panier »

Type : user story

Description :
En tant que client,
je souhaite pouvoir ajouter un produit dans mon panier
afin de pouvoir l’acheter

Règles métiers :
Le bouton ajouter au panier sur la fiche produit apparait si il reste un produit en stock public. (stock marchand – stocke réservé)
Quand j’ajoute un produit au panier, le client arrive sur la page panier
Si j’ajoute un produit au panier, ça le réserve pendant 1h
Quand j’ajoute le produit au panier et que j’ai déjà ce produit au panier, on rajoute +1 à la quantité.

Tests d’acceptances :

Scénario:
Etant donné que je suis sur mon panier
Et que j'ai un produit d'id "1234" en quantité "1"
Et que le stock public restant sur ce produit est de "0"
Et que j'ai ce produit en quantité "0' dans mon panier
Quand je veux cliquer sur le bouton ajouter au panier
Alors rien en se passe

Scénario:
Etant donné que je suis sur mon panier
Et que j'ai un produit d'id "1234" en quantité "1"
Et que le stock public restant sur ce produit est de "1"
Et que j'ai ce produit en quantité "0' dans mon panier
Quand je veux cliquer sur le bouton ajouter au panier
Alors j'arrive sur la page panier
Et j'ai "1' quantité de ce produit dans mon panier.

Scénario:
Etant donné que je suis sur mon panier
Et que j'ai un produit d'id "1234" en quantité "1"
Et que le stock public restant sur ce produit est de "1"
Et que j'ai ce produit en quantité "1' dans mon panier
Quand je veux cliquer sur le bouton ajouter au panier
Alors j'arrive sur la page panier
Et j'ai "2' quantité de ce produit dans mon panier.

Conclusion user stories

Maintenant que vous avez bien compris comment créer ses user stories dans un format classique, vous êtes prêt pour créer un backlog complet. Le format proposé est un classique mais n’hésitez pas à l’adapter selon les besoins de vos équipes.

Dans un prochain article, nous verrons alors comment nous allons gérer nos user stories dans notre backlog ; en effet, il est essentiel également de bien prioriser les user stories dans un product backlog.

Si vous avez des astuces à partager autour des user stories, n’hésitez pas à le faire en commentaire.

Lien utile : Product backlog refinement (english)