Votre récit utilisateur porte-t-il une intention ? Une comparaison côte à côte
Lorsque les équipes sont passées au télétravail en 2020 et sont restées en mode hybride jusqu'en 2021, un problème discret a fait surface dans bien des carnets. Avec moins de discussions de couloir pour combler les écarts, les mots inscrits sur la fiche devaient en faire davantage. Un récit utilisateur qui survivait autrefois parce qu'on pouvait poser une question à son voisin de bureau se retrouvait maintenant bloqué parce que personne n'en saisissait vraiment le sens. La solution n'est pas plus de cérémonie. C'est d'écrire des récits qui portent une intention.
Scrum lui-même dit très peu de choses sur la façon d'écrire un élément du carnet de produit. Le Guide Scrum laisse le format au choix de l'équipe. Les récits utilisateurs sont simplement la convention la plus répandue, et le modèle populaire — en tant que [rôle], je veux [capacité], afin de [résultat] — n'est utile que si la troisième partie est honnête. Retirez le « afin de » et il ne reste qu'une demande de fonctionnalité déguisée en agilité.
À quoi ressemble un récit faible
Les récits faibles décrivent l'interface, pas le besoin. Ils glissent la solution dans l'exigence, de sorte que l'équipe construit exactement ce qui est écrit et découvre trop tard que cela n'a rien résolu. Ils partagent souvent quelques traits.
« En tant qu'utilisateur, je veux une liste déroulante de provinces. » — Un élément d'interface, pas un objectif. Pourquoi l'utilisateur doit-il choisir une province ?
« En tant qu'administrateur, je veux un rapport. » — Aucun résultat, aucune portée. Quelle décision ce rapport appuie-t-il ?
« En tant que client, je veux que le système soit rapide. » — Besoin réel, mais non vérifiable. Rapide par rapport à quoi, mesuré comment ?
Un récit si vaste qu'il ne peut jamais se terminer dans un sprint, qui traîne sur trois et bloque tout ce qui le suit.
À quoi ressemble un récit solide
Un récit solide nomme une personne, une capacité et le résultat qui rend cette capacité utile — puis laisse à l'équipe le soin de décider du comment. Il est assez petit pour être terminé, et il vient avec des critères d'acceptation qui indiquent quand il est fini.
Il énonce un résultat réel. « En tant que surveillant de chantier, je veux signaler une livraison incomplète afin que l'approvisionnement relance le fournisseur avant la prochaine coulée. » Le « afin que » est vérifiable et lié à une décision.
Il est indépendant et négociable. La fiche ouvre une conversation plutôt que de la clore. Le surveillant et le développeur peuvent encore discuter du moyen — un signalement, une photo ou un champ de quantité — qui sert le mieux l'objectif.
Il est petit et vérifiable. Il tient dans un sprint et porte des critères d'acceptation — « le signalement apparaît au tableau de bord de l'approvisionnement en un rafraîchissement » — de sorte que « terminé » n'est pas une affaire d'opinion.
Il survit sans son auteur dans la pièce. Un collègue à trois fuseaux horaires de distance peut le lire à froid et construire la bonne chose. C'est le véritable test de l'intention.
Remarquez que l'exemple solide vient du monde des chaînes d'approvisionnement de 2021 : livraisons incomplètes, coulées ratées, fournisseurs à relancer. Le récit portait une intention parce qu'il décrivait ce qu'une personne cherchait à accomplir, et non quel contrôle afficher. Gardez le « pourquoi » visible et le reste de la conversation sur le carnet devient plus facile — estimation, découpage et priorisation reposent tous sur un objectif que l'équipe peut réellement voir.
Un test rapide avant l'affinage
Avant de tirer un récit dans un sprint, soumettez-le à deux questions. Premièrement, pouvez-vous énoncer le résultat sans nommer un écran, un bouton ou une table de base de données ? Si vous en êtes incapable, vous tenez une solution, pas un besoin, et vous avez fermé la porte aux meilleures idées que l'équipe aurait pu apporter. Deuxièmement, un développeur qui n'a jamais rencontré le demandeur construirait-il la bonne chose à partir de la seule fiche ? Si la réponse honnête est non, l'intention vit dans la tête de quelqu'un, pas sur la fiche — et dans une équipe distribuée, cette tête peut être hors ligne quand le travail commence.
Rien de tout cela n'exige un procédé plus lourd. Un bon récit est souvent plus court qu'un mauvais, parce qu'il cesse de décrire l'interface et se met à nommer l'objectif. Les critères d'acceptation font le travail de précision ; le récit lui-même n'a qu'à rendre le but indubitable. Quand l'intention est sur la fiche, l'affinage devient une conversation sur la meilleure solution plutôt qu'une fouille archéologique de ce que le demandeur voulait vraiment dire.
Si votre carnet regorge d'écrans plutôt que de résultats, le conseil en exécution de programmes et de projets de XNM peut aider vos équipes à rédiger des exigences qui portent une intention et survivent au transfert.