Qu'est-ce qu'une rétrospective Definition of Ready ?
Un sprint se passe mieux quand le travail qu'il contient était prêt avant le sprint planning. La Definition of Ready (DoR), ou définition de prêt, est la liste des critères d'entrée qu'un élément du backlog doit remplir avant d'être intégré à un sprint : critères d'acceptation, estimation, dépendances identifiées, etc. La rétrospective Definition of Ready permet de vérifier si cette liste remplit bien son rôle. Le tableau comporte quatre colonnes. Notre DoR actuelle pose les critères tels qu'ils sont réellement appliqués aujourd'hui, et on découvre souvent qu'ils varient d'une personne à l'autre. Quand ça marche rassemble les exemples de stories prêtes qui se sont bien déroulées. Quand ça coince revient sur ce qui s'est passé lorsque du travail pas prêt est entré dans un sprint. Améliorer notre DoR sert à décider des changements à apporter. Utilisez-la quand le sprint planning s'éternise, que les stories restent bloquées en cours de sprint ou que personne n'a relu votre DoR depuis des mois. Elle convient aussi bien aux équipes Scrum qu'aux équipes Kanban. Dans TeamRetro, chacun peut ajouter ses idées de façon anonyme, ce qui permet de faire remonter les problèmes d'affinage même quand ils sont délicats à aborder.
Format de rétrospective Definition of Ready
Notre DoR actuelle
À quoi ressemble notre Definition of Ready aujourd'hui ?
Demandez à chacun d'écrire les critères actuels tels qu'il les comprend. Beaucoup d'équipes ont une DoR informelle ou non écrite, et les écarts entre les réponses vous indiquent par où commencer.
Quand ça marche
Qu'est-ce qui se passe bien quand les stories respectent notre DoR ?
Cherchez des sprints ou des stories précis où le fait d'être prêt a fait la différence, comme un sprint planning court ou une story terminée sans avoir à relancer personne. Ces exemples montrent à l'équipe pourquoi la DoR vaut la peine d'être entretenue.
Quand ça coince
Quels problèmes surviennent quand les stories ne sont pas vraiment prêtes ?
C'est souvent la colonne la plus parlante. Demandez des stories précises entrées dans un sprint sans respecter la DoR, et ce qui s'est passé ensuite. Cherchez les tendances : est-ce toujours les mêmes manques qui reviennent, ou les mêmes types de stories qui sont touchés ?
Améliorer notre DoR
Que devons-nous changer pour renforcer notre Definition of Ready ?
Mettez-vous d'accord sur des changements concrets : ajouter ou retirer des critères, modifier le déroulement de l'affinage ou ajuster vos outils. Visez 1 à 3 changements à tester au prochain sprint.
Dans quels cas recourir à cette étude rétrospective ?
- Votre équipe se heurte régulièrement à des blocages en cours de sprint, à une dérive du périmètre ou à des stories impossibles à terminer dans le sprint, souvent signe que le travail n'était pas prêt au moment du planning.
- Le sprint planning s'éternise ou paraît chaotique parce que le backlog n'a pas été affiné avant que l'équipe s'engage.
- Vous intégrez de nouveaux membres et voulez formaliser ce que « prêt » signifie pour votre équipe.
- Votre équipe a une Definition of Ready mais ne l'a pas revue depuis un moment, et elle ne correspond peut-être plus à votre façon de travailler.
- Après un sprint difficile où des exigences floues ou des informations manquantes ont causé des retards ou du travail à refaire.
Exemples de questions pour brise-glace
- Si votre backlog était une cuisine, serait-ce un garde-manger bien rangé et bien rempli, ou un frigo en désordre plein de restes non identifiés ? Pourquoi ?
- Quelle est la chose que vous aimeriez savoir au début d'une tâche et que vous semblez toujours découvrir à mi-parcours ?
Vous souhaitez un exercice d'échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glaces gratuits →
Idées et conseils pour votre réunion de rétrospective
- Partagez votre DoR actuelle avant la séance pour que chacun arrive avec des exemples concrets.
- Parlez des failles du processus, pas des erreurs individuelles, pour que chacun puisse raconter ce qui n'a pas marché sans craindre d'être blâmé.
- Limitez le temps passé sur chaque colonne. Les discussions sur la DoR dérivent facilement vers l'affinage de stories précises : gardez la rétro centrée sur les critères eux-mêmes.
- Décidez de 1 à 3 changements par séance. Une DoR qui veut tout couvrir devient trop longue pour être suivie.
- Impliquez toute l'équipe, pas seulement le Scrum Master ou le Product Owner. Développeurs, QA et designers subissent chacun à leur manière les stories pas prêtes.
- Vérifiez à la rétrospective suivante si les changements ont facilité le planning et la livraison.