Une Definition of Ready vraiment utile : une liste de vérification pour cette semaine
Une Definition of Ready (DoR) est une entente commune sur le moment où un élément du Backlog de produit est assez clair pour entrer dans un Sprint. Précisons-le d'emblée : le Guide Scrum ne la mentionne pas — Scrum prévoit une Definition of Done, pas une Definition of Ready. La DoR est donc un ajout que l'équipe choisit, et elle doit mériter sa place. Bien utilisée, c'est une vérification rapide qui empêche des éléments vagues ou à moitié formés d'arriver en planification de Sprint et de couler discrètement le Sprint. Mal utilisée, elle devient une barrière contrôlée par un groupe distinct de « exigences », ce qui va à l'encontre de l'esprit de Scrum.
À la mi-2021, alors que beaucoup d'équipes étaient encore réparties entre bureaux à domicile et que les délais d'approvisionnement restaient incertains, le coût d'un élément de backlog mal compris a augmenté. On ne pouvait plus régler une ambiguïté en trente secondes par-dessus un bureau. Une DoR courte et honnête aidait les équipes distribuées à faire émerger ces questions avant le début du Sprint, et non trois jours plus tard.
La liste de vérification de terrain
Traitez ce qui suit comme des amorces de conversation lors du raffinement, pas comme un formulaire à signer. Si un élément échoue à la plupart de ces points, il n'est sans doute pas prêt — et la solution est en général une conversation de cinq minutes, pas un refus.
L'élément décrit le résultat attendu ou le besoin de l'utilisateur, pas seulement une solution déjà décidée par quelqu'un.
Des critères d'acceptation existent et sont assez précis pour que l'équipe s'entende sur ce à quoi ressemblera le « terminé ».
Les dépendances sont connues — une autre équipe, un fournisseur, une approbation, une donnée — et aucune ne bloque le démarrage du travail.
L'élément est assez petit pour être plausiblement terminé dans un Sprint; s'il ne l'est manifestement pas, on le découpe d'abord.
Les Développeurs ont une compréhension suffisante pour l'estimer, même grossièrement, sans devoir d'abord mener un projet de recherche.
Tout ce dont l'équipe a besoin — données de test, accès, conception, décision — est disponible ou en voie de l'être clairement.
Comment la garder légère
Faites-en l'affaire de l'équipe, pas un point de contrôle. Les Développeurs et le Product Owner sont copropriétaires de la DoR. C'est un outil pour les conversations de raffinement, jamais une barrière de transfert gérée par des gens extérieurs à l'équipe Scrum.
Limitez-la à quelques points. Cinq ou six amorces que l'équipe utilise vraiment valent mieux qu'une politique de vingt lignes que personne ne lit. Si une vérification ne détecte jamais rien, supprimez-la.
Appliquez-la comme une ligne directrice, pas une loi. L'état de préparation est un continuum. Un élément prêt à 70 % que l'équipe comprend peut très bien être tiré; la DoR sert à révéler le risque, pas à interdire le jugement.
Réexaminez-la en Rétrospective. Si des éléments arrivent toujours non prêts, ou si la DoR ralentit le raffinement à l'excès, changez-la. Comme tout dans Scrum, elle doit s'améliorer par l'inspection et l'adaptation.
L'échec le plus fréquent consiste à traiter l'état de préparation comme un tampon binaire plutôt que comme une conversation. Une DoR n'est pas un contrat remis par un analyste d'affaires aux Développeurs; c'est une habitude que toute l'équipe Scrum pratique pendant le raffinement, afin que le backlog conserve quelques éléments prêts et bien compris. Dès qu'une DoR engendre des disputes pour savoir si un élément a « réussi », l'équipe a en général glissé vers une logique de jalons et perdu le fil. Le signal à surveiller est simple : le raffinement doit ressembler à une équipe qui se met d'accord, pas à une inspection.
Le but d'une Definition of Ready n'est pas d'ajouter du cérémonial. C'est de faire en sorte que l'équipe consacre la planification de Sprint à décider comment livrer de la valeur, plutôt que de découvrir à mi-parcours que personne ne s'entendait sur la nature même du travail. Gardez-la courte, gardez-la à l'équipe, et laissez la Rétrospective l'élaguer.
Si vos équipes de livraison entament sans cesse un travail qui s'avère à moitié défini, le conseil en exécution de programmes et de projets de XNM peut vous aider à resserrer le passage de l'idée au Sprint.