Idée principale

La user story a été conçue comme une promesse de discussion : une phrase courte, volontairement incomplète, dont la fonction est de faire venir les bonnes personnes autour du sujet. Traitée comme un contrat, elle devient l'inverse — un texte qu'on exécute sans parler à son auteur, et dont on se sert ensuite pour établir qui avait tort.

La conséquence pratique porte sur celui qui reçoit la carte. Un développeur ne doit pas accepter un ticket qu'il ne comprend pas : s'il manque des éléments pour évaluer la faisabilité, il les demande ; s'il manque le contexte métier, il le demande ; s'il ne voit pas la valeur, il le dit. Ce refus n'est pas une objection de principe, c'est le mode d'emploi de l'artefact.

Pourquoi c'est important

Cela déplace la responsabilité de la qualité d'un ticket. Elle n'est pas entièrement du côté de celui qui écrit : la carte est un point de départ, et celui qui la prend a le devoir de la faire compléter.

Cela explique aussi pourquoi l'amélioration continue des gabarits ne règle rien. Ce qui manque à un ticket incompris n'est pas un champ supplémentaire, c'est une conversation qui n'a pas eu lieu.

Nuances et limites

Toutes les organisations ne peuvent pas compter sur la conversation : équipe distante sur plusieurs fuseaux, prestataire externe, relation contractuelle. L'écrit y porte alors une charge qu'il n'était pas fait pour porter, et il faut l'assumer comme un coût, pas comme une norme.

Et un développeur qui questionne chaque carte peut aussi bloquer le flux : la demande d'éclaircissement suppose qu'on sache distinguer le manque réel de l'inconfort.

Questions ouvertes

• Que devient l'exigence de conversation quand la réalisation est confiée à un tiers contractualisé ?