Rédiger des récits utilisateurs qui portent l'intention, pas seulement des tâches
Si vous avez côtoyé Scrum, vous connaissez la formule : « En tant qu'utilisateur, je veux un bouton, afin de pouvoir cliquer dessus. » Elle coche les cases et n'enseigne rien. Un récit utilisateur doit porter l'intention — la raison humaine derrière une demande — jusque dans le travail, afin qu'un développeur qui fait cent petits choix les fasse dans la bonne direction. Quand l'intention manque, l'équipe construit exactement ce qui est écrit et passe quand même à côté.
Le Guide Scrum n'exige en fait pas de récits utilisateurs. Il parle d'éléments du carnet de produit et du carnet de produit lui-même. Les récits utilisateurs sont une technique populaire pour exprimer ces éléments, pas une règle. Cette distinction compte : l'objectif est un carnet que les développeurs comprennent et que le Product Owner peut ordonner par valeur ; le format de récit n'est qu'un moyen fiable d'y parvenir.
Les trois parties qui comptent
Un bon récit répond à trois questions. Pour qui est-ce ? Que veulent-ils pouvoir faire ? Et pourquoi cela compte-t-il pour eux ? Le gabarit classique « En tant que / je veux / afin de » existe pour forcer la troisième question, celle que les équipes laissent le plus souvent tomber. C'est dans le « afin de » que réside la valeur. Un récit sans cela est une tâche déguisée.
Voyez la différence. « En tant que chef de chantier, je veux exporter le journal quotidien en PDF » est une tâche. « En tant que chef de chantier, je veux exporter le journal quotidien en PDF, afin de remettre aux inspecteurs un dossier sans leur donner accès au système » dit à l'équipe à quoi ressemble la réussite et ouvre de meilleures solutions. Le vrai besoin est peut-être un lien de partage en lecture seule, pas un PDF du tout.
Comment en rédiger qui tiennent
Ancrez-le à une personne réelle. Nommez le rôle réel, pas un vague « utilisateur ». Un responsable des achats et un travailleur de terrain veulent des choses différentes ; le récit doit préciser lequel.
Commencez par le résultat, pas par l'écran. Décrivez ce que la personne doit accomplir, en laissant à l'équipe la latitude de trouver la meilleure façon de le livrer. Prescrire l'interface trop tôt gaspille leur expertise.
Ajoutez des critères d'acceptation, pas un design. Énumérez les conditions qui rendent le récit terminé — les vérifications qu'un relecteur peut confirmer. Elles rendent le « afin de » testable sans dicter la mise en œuvre.
Gardez-le assez petit pour le finir. Si un récit ne peut raisonnablement pas être terminé dans un Sprint, découpez-le selon la valeur qu'il livre, pas selon les couches techniques. Deux fines tranches qui fonctionnent valent mieux qu'une grosse tranche qui fonctionne à moitié.
Affinez-le ensemble. L'affinage du carnet est le moment où l'équipe pose des questions et où le Product Owner clarifie. Un récit est l'amorce d'une conversation, pas un contrat imposé d'en haut.
Signes qu'un récit a perdu son intention
Chaque récit nomme le même « utilisateur » générique, de sorte que personne ne peut se figurer qui est réellement touché.
La clause « afin de » répète le « je veux » — « afin de pouvoir exporter » — ce qui ajoute des mots mais aucune raison.
Le récit précise boutons, champs et mises en page, laissant l'équipe taper au clavier plutôt que réfléchir.
Il est trop gros pour être fini dans un Sprint et continue d'avancer sans être touché.
En 2022, avec des équipes réparties entre maison et bureau et des budgets serrés par la hausse des coûts, le coût de construire la mauvaise chose est plus élevé que jamais. Un récit utilisateur qui porte l'intention est une assurance peu coûteuse : il permet à un développeur seul à 21 h de faire le même choix que le Product Owner aurait fait. C'est tout l'intérêt de le mettre par écrit.
Si votre équipe veut des carnets qui créent de la valeur au lieu de simplement lister des tâches, le conseil en réalisation de programmes et de projets de XNM peut vous aider à affiner la façon dont le travail est formulé.