Plus personne ne sait ce qu'est une User Story

Pas un jour ne passe sans que je lise des user stories du type :

As a user, I want to connect to the database
So that I'm connected to the database.

Si vous êtes l'auteur de ce forfait, cessez de vous morfondre, vous serez amnistié gratuitement en fin d'article.

Car naturellement, ces lignes n'ont rien d'une user story. Elles en ont l'apparence ("As a user, I want to… so that I…"), mais l'habit ne fait pas le moine. Mis à part le cas très précis où vous et vos collègues développeriez un outil de gestion de bases de données, sachez qu'aucun utilisateur ne veut se connecter à votre base de données 🥲.

Non, Frank veut réserver son billet de train pour rendre visite à Tatie Danielle, Mélanie veut renouveler ses chaussures de running pour courir son prochain 10k et moi, je veux écrire mon post LinkedIn. Mais ni Frank, ni Mélanie ni moi-même n'avons que faire de votre base de données.

Ainsi, une user story doit impérativement apporter de la valeur à vos utilisateurs.

En l'état, d'ailleurs, cette chose est une tâche : quelque chose à faire à un moment donné du développement. Vous me direz, pourquoi ne pas écrire des tâches ? Ou pourquoi ne pas spécifier et développer directement des fonctionnalités ? Autant de questions qu'il faut se poser pour comprendre vraiment ce qu'est une user story.

Revenons un peu en arrière.

Le problème des fonctionnalités, c'est qu'elles sont souvent beaucoup trop grosses. Leur développement signifie des jours, voire des semaines entières de travail. C'est problématique :

1. Vous prenez le risque de développer des choses inutiles ou non-prioritaires. Ce que vous voulez, c'est mettre en production le plus tôt possible pour avoir du feedback utilisateur et ajuster le tir si nécessaire. Certes, une bonne user research minimise le risque, mais le retour d'usage en production reste le juge de paix.

2. Vous vous exposez à un fort effet tunnel : tant que tout n'est pas fait, c'est comme si rien n'était fait. Si pour une raison quelconque il faut absolument mettre en production demain, c'est impossible. Pourquoi ? Parce que votre back-end est parfait (un domaine joliment isolé, une API REST bien pensée), mais il n'y a pas de front (*).

3. Il y a trop à faire, tout développer d'un coup n'est pas une option. Monsieur Descartes ne disait pas autre chose dans son Discours de la méthode. Ça vaut pour l'agilité, ça vaut pour le Test-driven development, ça vaut pour tout. Fort, le René, et avec 4 siècles d'avance s'il vous plaît.

Au fond, si vous y réfléchissez, l'utilisateur n'a que faire de vos user stories. Lui ne connaît que son "job to be done" et serait a priori très content si vous lui livriez des fonctionnalités. Il y a user stories parce que vous, équipe de développement, avez besoin de découper votre travail. Pas en tâches mais en user stories, parce que des tâches ne sont pas utilisables en production.

Jusqu'où découper ? Soyons simples : si vous pouvez découper, faites-le. Vous aurez ainsi des atomes. Quitte à en développer 2 ou 3 dans la foulée.

Allez, amnistie générale et… y'a plus qu'à !

(*) Et non, je vous vois venir, aucun utilisateur normal ne va interroger directement votre API.