Rédiger des récits utilisateurs qui ont encore un sens le jour du sprint
Le Guide Scrum ne mentionne jamais les récits utilisateurs — ils ne font pas partie de Scrum lui-même, ce n'est qu'une façon répandue d'exprimer les éléments du Carnet de produit. Cela compte, car cela vous libère pour bien les utiliser plutôt que par habitude. Un bon récit utilisateur n'est pas un cahier des charges miniature. C'est, selon la formule de Ron Jeffries, un prétexte à une conversation : un court énoncé de qui a besoin de quoi et pourquoi, assez pour planifier, le détail venant quand l'équipe et le Product Owner se parlent vraiment. Dans des équipes réparties, où cette conversation se tient désormais en visioconférence plutôt qu'au coin d'un bureau, le récit doit porter à lui seul davantage d'intention. Voici une liste pour en rédiger ainsi.
Avant que le récit n'entre dans un sprint
Nommez le véritable utilisateur. « En tant qu'utilisateur » n'apprend rien. « En tant que répartiteur de nuit » dit le contexte, les contraintes et ce à quoi ressemblera le « terminé ».
Énoncez le pourquoi, pas seulement le quoi. La clause « afin de » est le siège de la valeur. Si vous ne pouvez pas la compléter, vous bâtissez peut-être ce que personne n'a demandé.
Rendez-le utile en lui-même. Un récit doit livrer quelque chose d'utilisable, pas une couche technique inutile tant que trois autres récits ne sont pas livrés.
Ajoutez des critères d'acceptation convenus par l'équipe. Ce sont les conditions qui rendent le récit « terminé » — concrètes, testables, écrites avant le travail, pas inventées en cours de revue.
Un test rapide pour chaque récit
Est-il assez petit pour tenir dans un sprint ? Si l'équipe ne le voit pas achevé en un sprint, découpez-le selon des lignes visibles par l'utilisateur, pas techniques.
Quelqu'un d'autre que l'auteur peut-il l'estimer ? Si seul le rédacteur le comprend, la compréhension commune que le récit devait créer n'existe pas encore.
Évite-t-il de dicter la solution ? Énoncez le besoin et le résultat; laissez le « comment » aux Développeurs. Un récit qui impose la mise en œuvre gaspille leur expertise.
Les critères d'acceptation sont-ils testables ? « Fonctionne bien » n'est pas un critère. « Renvoie des résultats en deux secondes pour une recherche sur 10 000 lignes » en est un.
La valeur reste-t-elle évidente pour un inconnu ? Lisez-le comme quelqu'un qui a manqué la conversation. Si l'intention survit, le récit la porte.
Ce que le récit n'est pas
Ce n'est pas un contrat qui dispense l'équipe de parler. Ce n'est pas un endroit où enfouir tout un document d'exigences. Et ce n'est pas la liste de tâches privée du Product Owner — tout l'intérêt du Carnet de produit est qu'il soit transparent et affiné ensemble. La discipline, c'est la retenue : écrire juste assez pour que la bonne conversation ait lieu, consigner l'accord dans les critères d'acceptation, et résister à l'envie de tout spécifier d'emblée. Des récits porteurs d'intention permettent à une équipe de bâtir ce dont l'utilisateur avait besoin, et pas seulement ce que le ticket décrivait.
Si votre carnet est devenu un tas de tickets auxquels plus personne ne se fie, le conseil en réalisation de programmes et de projets de XNM peut aider vos équipes à rédiger des récits qui font avancer le travail, pas seulement à le suivre.