User story agile INVEST ?

Dans cet article, nous allons voir ce qu’est une user story agile INVEST car si l’acronyme est simple, on a plus de mal à voir concrètement en quoi cela consiste.

Vous pouvez aussi regarder notre vidéo sur le sujet :

L’acronyme agile INVEST

L’acronyme INVEST veut dire :

• I pour Indépendante : chaque user-story doit être indépendante des autres au moins sur le sprint en cours.
• N pour négociable : les détails doivent être négociables. C’est pour cela qu’on écrit une user-story en une seule petite phrase afin de ne pas forcer les détails
• V pour valeur : chaque user story doit apporter de la valeur business pour les métiers ou les clients
• E pour Estimable : chaque user-story doit être estimable par les équipes de développement ; pour cela, ces équipes doivent bien les comprendre.
• S pour Suffisamment petite : chaque user story doit être bien découpée afin d’être livrée au sein d’un seul Sprint.
• T pour Testable : il faut que toutes les user story soient testables.

Maintenant nous allons rentrer dans les détails car je me suis aperçu que ce n’était pas si simple à comprendre pour tout le monde avec ces quelques lignes. Plus concrètement, qu’est-ce être une user story INVEST ?

User story Indépendante

J’entends souvent qu’il n’est pas possible d’être totalement indépendant au niveau des user-story.

C’est totalement vrai si on s’arrête sur ce terme mais en fait on parle de dépendance technico/fonctionnelle et non pas de dépendance business. La frontière est mince mais totalement réelle.

Si je fais un site e-commerce, j’aurais une user story pour m’authentifier et une user story pour créer mon compte par exemple.

Il est évident qu’un niveau business, pour s’authentifier, il est obligatoire de créer son compte mais sur le plan technico/fonctionnel ce n’est pas le cas. Les développeurs pourraient très bien faire l’authentification sans avoir de création de compte. Si cela a peu de sens niveau business, c’est totalement faisable sur le plan technique.

On pourra donc bien définir que ces deux user stories sont indépendantes même si ça n’aurait pas de sens de sortir le produit l’une sans l’autre.

User story négociable

On commence une user story par un simple résumé de la fonctionnalité désirée. Rien n’interdit de mettre des détails comme des règles de gestion mais le tout doit être écrit de façon très simple pour que les développeurs voire les clients la comprennent rapidement.

Une user story est négociable en phase d’affinage (product backlog refinement) par exemple si l’ensemble des développeurs n’ont aucun soucis de compréhension de celle-ci. Utilisez donc toujours des mots simples au point de vous dire si un enfant de 10 ans peut comprendre le contenu de votre user-story.

User story avec une vraie valeur

Ce point est parfois très mal compris mais on utilise le concept de user story que pour une demande fonctionnelle qui a une vraie valeur pour l’un (ou des) utilisateurs types de l’application.

Je vois parfois des « En tant que développeurs, je souhaite que la base de données soit pleine »… Cela n’a aucune valeur pour l’un des utilisateurs types donc à éviter à tout prix.

N’hésitez pas dans ce type de cas à vous autoriser à faire des storyotypes : article Faire des items de différents storyotypes. Tout ce qui n’a pas de valeur pour les utilisateurs types devraient passer par d’autres types d’items.

Le fait d’utiliser les « En tant que… » uniquement pour de vraies user story permet de bien différencier les items qui ont de la valeur business et celles qui en ont pas.

User story estimable

Chaque user story sera estimée par les développeurs si on n’est pas dans le cadre d’une philosophie #NoEstimate ; sinon les développeurs auront quand même par défaut une idée d’estimation dans la tête.

L’ensemble des critères que nous avons vu et celui d’après doit normalement permettre aux développeurs de facilement estimer les user stories ; d’ailleurs, si il n’y arrivent pas, ils demanderont plus de détails au Product Owner.

User story suffisamment petite

Une user story doit être réalisable en un seul sprint ; au moindre doute, elle devra être redécoupée en plusieurs user stories. En général, on conseille au Product Owner de découper au maximum chacune des user stories (tant que les user stories filles restent INVEST).

User story testable

Ce point est relativement simple à comprendre, chacune des user stories doit être testable. D’ailleurs par rapport à ça, on demande au Product Owner de mettre une fin visible sur la user-story.

Voici un exemple pour bien comprendre.

En tant que client, je souhaite naviguer sur le site -> cette action n’a pas de fin concrète, il peut naviguer sur plusieurs pages sans s’arrêter.

En tant que client, je souhaite ajouter un produit dans mon panier -> cette action a une fin concrète indiscutable.

Conclusion INVEST agile

Vous avez à présent tout ce qu’il faut en main pour faire de vraies user stories INVEST et surtout de bien comprendre concrètement ce que veut dire cet acronyme INVEST.

Mot-clé : invest scrum