Lorsque nous souhaitons mettre en place une démarche Lean, la définition de notre flux de production est indispensable pour visualiser les obstacles nous empêchant de délivrer rapidement de la valeur à notre client. Un des points importants dans cette définition est la spécification de l’élément qui va traverser notre flux de production de valeur.

Dans ce billet, je vais expliquer pourquoi, et dans quel cas je favorise le format de la user story, et en quoi celui-ci est compatible avec le Lean. Je vais également répondre à une question somme toute intéressante, qu’est-ce qu’une user story ? 🙂

Une user story ?

Une user story (histoire utilisateur en français) est une méthode d’expression d’un besoin client. C’est un élément de travail assez petit pour pouvoir être utilisé dans un flux de production. On peut communément admettre qu’une bonne user story se décompose en 3 parties : la définition, les tests d’acceptations, l’estimation.

• La définition

Une user story s’exprime de la façon suivante :

En tant que <rôle>
Je peux <action>
Afin de <valeur métier>

Ce format permet de définir un besoin tout en exprimant la vision métier. Le rôle est l’utilisateur final qui va réellement utiliser la fonctionnalité que nous nous apprêtons à produire. L’action représente ce que l’utilisateur final souhaite réaliser qu’il ne peut faire aujourd’hui. Et enfin le plus important, la valeur métier est ce pourquoi nous faisons le développement. Quelle valeur ce développement va apporter à notre produit et surtout à notre client ? Ceci est LE point important lorsque nous faisons du Lean.

• Les tests d’acceptation (ou d’acceptance)

Par la définition des tests d’acceptation, le client / product owner exprime comment valider la réalisation, et met ainsi le développeur en situation de réussite. Là encore, c’est exactement ce que nous cherchons à faire en Lean lorsque nous parlons de qualité à chaque étape. Qu’est-ce que signifie réussir cette user story ?

Il n’est pas rare d’exprimer un test d’acceptation en utilisant le format « Gherkin » issue du BDD (Behavior Driven Development) qui se définit comme suit :

Etant donné <contexte initiale>
Lorsque <événement>
Alors <résultat 1>
Alors <résultat 2>
…

Ce format permet d’exprimer une condition de validation. Il a l’avantage d’être compréhensible par toutes les parties prenantes travaillant de prêt ou de loin sur le projet. Elle définit un contexte initial (je me trouve sur telle ou telle page, je suis connecté, je suis avec un rôle particulier), un événement (je clique sur « home », je tape un mauvais mot de passe, je renseigne une date au mauvais format), et des résultats (alors je suis redirigé vers la page de connexion, alors je suis déconnecté, alors je vois un message d’information).

• L’estimation

L’estimation relative via planning poker est un outil d’alignement très puissant permettant de conforter le fait que chaque membre de l’équipe a bien la même vision du besoin exprimé, de la faisabilité et de la complexité. Si une personne a une vision de l’effort bien éloigné du reste du groupe, c’est certainement qu’elle voit une contrainte que les autres n’ont pas vu, ou au contraire qu’elle voit une complexité là où il n’y en a pas. Ou encore qu’elle (ou les autres) n’a(ont) pas bien compris le besoin. Toujours est-il que cette pratique ouvre des discussions très intéressantes jusqu’à ce que tout le monde soit aligné sur une même vision.

Pourquoi la user story ?

Ne me faites pas écrire ce que je n’ai pas pensé. La user story n’est pas à utiliser aveuglément dans tous les cas. Par exemple, lorsque nous avons une activité de support, ou même de maintenance, la user story n’est pas forcément adaptée. Cependant, le format colle tout particulièrement aux équipes produisant de nouvelles fonctionnalités.

Voici les points qui motivent mon choix d’utiliser la user story :

• Valeur métier

La user story représente un besoin client et donc de la valeur pour ce dernier. En d’autres termes, une user story EST une valeur ajoutée pour notre client, ce qui est au cœur de ce que nous souhaitons réaliser dans le Lean. C’est un réel changement de posture que d’utiliser ce format. C’est piloter son projet par la valeur client plutôt que par la capacité du système.

Le fait d’exprimer un besoin laisse en plus la communication ouverte sur la solution. La négociation est alors ouverte sur la solution pour répondre à un besoin avec un effort maîtrisé. De plus, elle permet de bien partager la vision du client si cher à tous Leaneux et autres Agilistes.

• Communication

Un point très intéressant de la user story, c’est qu’elle favorise la communication au sein de la chaîne de production de valeur. En effet, la chaîne est souvent représentée par plusieurs acteurs / équipes (ex : le product owner définit le besoin, l’équipe de développement réalise la demande, l’équipe de test valide, etc.). L’utilisation de la user story permet d’avoir un seul élément maîtrisé par tous les intervenants de la chaîne.

• Format efficace

Le format (détaillé plus haut) est redoutablement puissant. La définition avec le template « En tant que… », les tests d’acceptation, et l’estimation relative sont des outils d’alignement extrêmement efficaces pour partager tous ensemble une seule et même vision du besoin client et de la valeur qu’elle représente.

• Prédictibilité

La prédictibilité est un point très important et souvent cause principale de la réticence de beaucoup de monde à utiliser les story point. Cependant, l’utilisation de l’estimation relative (que je ne détaillerai pas dans ce billet) permet la définition de la vélocité de l’équipe. Celle-ci donne une prédictibilité à court et moyen terme du reste à faire très intéressante, et souvent bien plus juste qu’un reste à faire exprimer en jour homme.

 

INVEST

Je ne peux pas parler de user story sans parler du critère INVEST. Cet acronyme est un moyen mnémotechnique pour retenir les caractéristiques d’une user story.

• Independant : Une user story doit être indépendante des autres.
• Negociable : Elle doit exprimer un besoin et non une solution (qui reste à négocier).
• Value : Elle doit représenter de la valeur pour notre client (notre produit).
• Estimable : Il doit y avoir consensus sur l’estimation donnée par chacun des membres de l’équipe (le besoin doit donc être bien défini et bien compris).
• Small : Elle ne doit pas être trop importante pour ne pas nuire à la fluidité du flux de production.
• Testable : Evidemment, des tests d’acceptation doivent être définis pour permettre au développeur de valider son développement.

Et vous, utilisez-vous les user stories ?