Une définition de « prêt » qui aide l'équipe au lieu de la bloquer
Le Guide Scrum ne mentionne jamais de définition de « prêt », et il vaut la peine de le dire franchement. Contrairement à la définition de « terminé », qui est un engagement formel envers l'Incrément, une définition de « prêt » (DdP) est une entente de travail optionnelle qu'une équipe Scrum peut choisir d'adopter. Bien utilisée, c'est une compréhension commune du moment où un élément du Backlog produit est assez clair pour être tiré dans un Sprint en confiance. Mal utilisée, elle devient un poste de contrôle qui affame le Sprint et érode la flexibilité même que Scrum existe pour protéger.
En 2022, avec des équipes distribuées qui s'installent dans le travail hybride et des dépendances qui s'étirent à travers les chaînes d'approvisionnement, la tentation de trop formaliser la préparation est forte. La solution n'est pas d'abandonner l'idée, mais de rester honnête sur sa raison d'être.
À quoi ressemble une définition de « prêt » utile
Une DdP utile est courte, appartient à toute l'équipe Scrum et est traitée comme un guide plutôt qu'un contrat. Elle existe pour rendre le raffinement productif et la planification de Sprint plus rapide, non pour se renvoyer le travail entre rôles.
Ce sont quelques vérifications conversationnelles, pas un long formulaire : l'élément a un résultat clair, l'équipe comprend grosso modo comment elle l'abordera, et il est assez petit pour être terminé dans un Sprint.
Les dépendances sont visibles et soit résolues, soit accompagnées d'un plan, afin que l'équipe ne parie pas sur quelque chose hors de son contrôle.
Les critères d'acceptation saisissent l'intention et les exemples clés, sans tenter de tout spécifier d'avance.
Elle est revue lors des rétrospectives et modifiée quand elle cesse d'aider, car elle appartient à l'équipe, et non à une police des processus.
À quoi ressemble une définition de « prêt » nuisible
La version dommageable part habituellement de bonnes intentions et se durcit en poste de contrôle. Les signes sont familiers à quiconque a vu le raffinement se transformer en tribunal.
Elle sert à rejeter des éléments à la planification de Sprint. Si les Développeurs refusent de discuter de tout ce qui n'est pas « prêt », le raffinement a été poussé en amont sur une seule personne et l'équipe a cessé de partager le travail de compréhension.
Elle exige une spécification complète avant tout travail. Exiger chaque détail, estimation et conception d'avance recrée un mini-cycle en cascade et retire l'apprentissage censé se produire pendant le Sprint.
Elle appartient à quelqu'un hors de l'équipe. Quand un gestionnaire ou un analyste distinct décide de ce qui est « prêt », la DdP devient une frontière de transfert plutôt qu'une entente commune, et la propriété du backlog quitte discrètement l'équipe.
Elle empêche le Product Owner d'ordonner le backlog. Si un travail à forte valeur ne peut être considéré parce qu'il n'a pas passé une liste de préparation, la liste prime désormais sur la valeur, ce qui renverse tout le but du Backlog produit.
La posture la plus saine consiste à traiter la définition de « prêt » comme une incitation au bon raffinement, non comme un laissez-passer. Le raffinement continu du Backlog produit, fait un peu à la fois tout au long du Sprint, rend habituellement une DdP lourde inutile, parce que les éléments arrivent à la planification déjà compris. Si vos règles de préparation créent une file d'attente de travail « pas encore prêt » et ralentissent la livraison, c'est le signal de les simplifier, non d'ajouter des cases à cocher.
Si les pratiques de préparation de votre équipe ont dérivé vers un poste de contrôle qui ralentit tout, le conseil en réalisation de programmes et de projets de XNM peut vous aider à recentrer le raffinement sur le flux et la valeur.