Une définition du « prêt » qui aide vraiment (et les façons de la rater)
Une définition du « prêt » (DoR) est une entente partagée sur le moment où un élément du backlog produit est assez clair pour être tiré dans un sprint. Disons-le d'emblée : elle ne fait pas partie du Guide Scrum. Le Guide nomme la définition du « terminé » comme un engagement formel, mais la définition du « prêt » est une entente de travail facultative qu'une équipe peut choisir d'adopter. Cette distinction compte, car les erreurs les plus fréquentes viennent de ce qu'on la traite comme une règle imposée plutôt que comme un outil que l'équipe possède.
Bien utilisée, une DoR est une vérification rapide avant la planification de sprint : comprenons-nous cet élément, pouvons-nous l'estimer, et pourrions-nous vraisemblablement le terminer en un sprint? Lorsque le télétravail a dispersé les équipes sur plusieurs fuseaux horaires en 2021, cette vérification a prouvé son utilité — on ne peut pas se pencher au-dessus d'un bureau pour demander ce que signifiait un élément flou quand son auteur est hors ligne jusqu'à demain. Des éléments assez clairs permettent aux équipes distribuées de planifier avec assurance au lieu de deviner.
Les erreurs qui la font tourner au vinaigre
En faire une barrière lourde. Dès qu'une DoR devient une longue liste que chaque élément doit satisfaire avant qu'on puisse y toucher, le raffinement s'enraye et les éléments s'accumulent en attendant une clarté parfaite. Scrum accueille le détail émergent; une DoR devrait élever la maturité, non exiger une certitude que personne n'a encore.
La confondre avec la définition du « terminé ». Le « prêt » concerne le fait de pouvoir commencer; le « terminé » concerne le fait que le travail est achevé et livrable. Les mélanger brouille les deux. Le « terminé » est un véritable engagement Scrum qui régit la qualité; le « prêt » est une aide à la planification. Gardez-en deux conversations distinctes.
L'écrire pour l'équipe au lieu de l'écrire avec elle. Une DoR imposée par un gestionnaire ou un seul Scrum Master tient rarement. Ce sont les développeurs et le Product Owner qui souffrent des éléments flous; ce sont donc eux qui devraient façonner l'entente. C'est l'appropriation qui pousse une équipe à s'en servir.
Exiger que l'estimation figure dans la DoR. Certaines équipes exigent une estimation en points avant qu'un élément soit « prêt », puis n'arrivent pas à estimer parce que l'élément est flou — une impasse. Mieux vaut exiger une compréhension partagée suffisante pour rendre l'estimation possible, et laisser l'estimation émerger au raffinement.
Ne jamais la revoir. Une DoR rédigée il y a un an pour une équipe colocalisée peut ne plus convenir à une équipe hybride. Traitez-la comme une entente vivante et ajustez-la en rétrospective lorsqu'elle cesse de mériter sa place.
À quoi ressemble une bonne DoR
Gardez-la courte et axée sur le résultat. Une DoR pratique ne demande souvent que quelques choses : l'élément décrit un résultat ou un besoin utilisateur clair; des critères d'acceptation existent et sont compris; les dépendances sont connues; et l'équipe le croit assez petit pour le terminer en un sprint. Cela suffit à planifier avec assurance sans figer le backlog.
La traiter comme une ligne directrice appliquée avec discernement, non une barrière rigide de type réussite/échec
La bâtir et la réviser au raffinement et en rétrospective, là où l'équipe possède déjà le travail
Viser « assez clair pour commencer et terminer », non « entièrement spécifié à l'avance »
Une définition du « prêt » est à son meilleur quand elle est presque invisible — une habitude discrète qui tient le travail à demi formé hors du sprint sans devenir de la bureaucratie. Si elle vous ralentit, c'est le signal de la simplifier.
Si vos équipes de livraison sont coincées entre des exigences floues et un processus rigide, le conseil en exécution de programmes et de projets de XNM peut vous aider à trouver le juste équilibre.