Et si la définition de prêt tuait nos histoires d’utilisateurs ?

Non, vous n’y avez pas échappé : l’enfer pour les Product Owners, ceux qui écrivent des histoires utilisateur (User Stories) longues comme des Conditions Générales de Vente. Celles-là mêmes que vous retrouvez en tout petit à la fin d’un contrat et que personne ne prend la peine de lire.
Et pourtant, vous aviez tout bien fait. Vous aviez coché toutes les cases de la définition de prêt (DOR). Alors comment se fait-il que cette user story “si prioritaire” passe autant de temps dans le backlog ? Et pourquoi se retrouve-t-elle encore refusée en sprint planning ? Et si la DOR était à l’origine de ce blocage dans le flux de travail ?

Tout part d’une bonne idée

L’intention, comme souvent, était bonne.

La définition de prêt est un guide de bonne rédaction des US, co-construit par l’équipe.

En explicitant les attendus, elle contribue à fluidifier l’affinage des besoins et facilite ainsi le travail au sein de l’équipe. Elle permet de vérifier que les user stories que l’équipe souhaite ajouter au backlog de sprint sont suffisamment matures et comprises pour être développées.
Dans certains cas, elle “protège” les développeurs d’un PO qui ferait le forcing pour intégrer au prochain sprint des fonctionnalités pas assez affinées, non « prêtes » à être développées ou trop complexes pour être prises d’un seul bloc.

Mais l’enfer est pavé de bonnes intentions

Dans les faits, il s’avère que la définition de prêt est souvent, et bien involontairement, détournée de son rôle. Présentée sous forme d’une checklist obligatoire, elle matérialise un contrat entre le PO et les développeurs et a donc pour conséquence de créer des silos à l’intérieur même de l’équipe.

Se servir de cet outil comme d’un “bouclier” pour les développeurs illustre déjà une mauvaise utilisation de la DOR et masque des problèmes dans la collaboration à l’intérieur de l’équipe.

Le deuxième (mauvais) effet KissCool est que le PO peut avoir tendance à présenter le besoin ET la solution par crainte que les dévs ne refusent d’intégrer l’US à leur backlog de sprint. La DOR peut ainsi éteindre les échanges sur une fonctionnalité et effacer toute la richesse qui peut sortir d’une belle discussion.

Alors comment faire mieux ?

Le propos n’est pas de dire que la définition de prêt est un mauvais outil. C’est seulement un outil. Pourtant le Manifeste Agile précise qu’il vaut mieux lui préférer les individus et leurs interactions. J’irais même plus loin en disant que les outils doivent servir les individus et leurs interactions. Une DOR trop fournie peut être symptomatique d’un manque de collaboration directe entre le PO et les développeurs. En aucun cas elle ne doit se substituer aux discussions entre les personnes.

Partons du principe qu’une user story est la promesse d’une discussion pour arriver à la compréhension mutuelle d’un besoin. En amont du dialogue sur une fonctionnalité, la définition de prêt aide le PO à anticiper les principaux aspects à éclaircir (métier, technique, réglementaire…). Elle ne se veut ni exhaustive, ni prescriptive.
L’objectif à terme, est que les membres de l’équipe aient la même compréhension du besoin et travaillent ensemble à une solution pour y répondre. L’autre avantage de cette discussion est que le PO n’écrira que ce qui est utile et nécessaire, éloignant ses efforts et ceux de l’équipe de ce qui n’a pas d’impact. Ensuite les développeurs et le PO collaboreront en confiance pendant tout le sprint pour aboutir au résultat attendu.