La definition of ready divise les équipes agiles, et même les agilistes les plus chevronné. Certains la jugent anti-agile et dangereuse. D'autres la jugent d'utilité publique.
Alors qui a tort ? Qui a raison ?
Décortiquons ça ensemble dans l'article.
Definition of ready : définition rapide
La definition of ready est une checklist permettant de vérifier la qualité d'une user story avant de commencer son développement. Elle participe à la qualité dans les projets agiles.
Cette checklist est définie conjointement en début de projet par le product owner et l'équipe de développement. Elle évolue ensuite au fur et à mesure des itérations, afin d'ajouter des critères de plus en plus stricts.
La definition of ready, quand elle est bien faite, apporte des avantages intéressants à l'équipe agile :
- Éviter les rituels à rallonge, comme le sprint planning.
Gain de temps, donc gain d'efficacité. - Simplifier le travail de rédaction des user stories.
Elle liste les bonnes pratiques qui caractérisent une user story de qualité. - Gagner en maturité sur l'estimation des user stories.
Les user stories sont mieux définies, l'estimation de l'équipe agile gagne ainsi en précision et l'incertitude diminue. - Donner des repères à votre équipe.
La definition of ready agit comme une guideline pour le product owner et l'équipe de développement.
La definition of ready est souvent mal utilisée
La definition of ready n'est pas une pratique officielle de Scrum. Elle n'est pas décrite dans le Scrum Guide.
Cette pratique est pourtant poussée par de grands noms de l'agilité comme Jeff Sutherland, le co-créateur de Scrum. Alors quel est le souci ?
le problème, c'est que la definition of ready est très souvent mal utilisée. Les équipes agiles qui utilisent la definition of ready pour identifier les user stories qui sont suffisamment détaillées pour passer en "To Do" dans le sprint backlog se fourrent le doigt dans l’œil.
Agir comme cela revient à faire pareil que le Waterfall, ou les autres méthodes prédictives. On prévoit tout à l'avance, on estime tout, on planifie tout, et il n'y a plus de place pour le changement.
Respecter la definition of ready n'est pas un prérequis du sprint backlog
L'objectif d'un sprint en Scrum est fixe. Mais le périmètre du sprint backlog est variable. Il est ouvert au changement.
Ce qui veut dire que tout ce qui est en To Do dans le sprint backlog n'est pas forcément en ready. Certaines user stories peuvent encore être affinées lors du sprint planning, voire même en cours de sprint.
La definition of ready est seulement là pour nous donner les bonnes pratiques en matière de spécifications des user stories.
Le “ready” est un critère de qualité pour dire que le minimum est requis pour lancer les développements... Et non que la user story ne sera plus jamais modifiable.
Si on prend le scrum guide, le “ready” pourrait être : description, estimation, valeur définie, un ordre (priorise) dans le backlog et des descriptions de tests.
Maintenant cela ne doit bloquer d’éventuelles modifications en cours de sprint si nécessaire (le périmètre d'un sprint est toujours variable et ouvert au changement).
Si l’équipe en sprint planning estime qu’il faudra un nouvel item pour atteindre l’objectif du sprint, elle mettra un item vide qui sera travaillé par le Product Owner en cours de sprint.
Les dangers de la definition of ready
Voici les pièges les plus fréquents que vous devez absolument éviter avec la definition of ready :
- Ne pas faire ce qui est marqué dans la definition of ready.
Si c'est écrit dans la definition of ready, il faut s'y conformer. Si ce n'est plus nécessaire, alors c'est le moment de revoir la definition of ready. - Être trop procédurier et trop exhaustif.
L'objectif de l'agilité est la collaboration entre tous les membres d el'équipe agile et les parties prenantes. Une definition of ready n'est pas fait pour que l'équipe de développement fasse front au Product Owner. - Considérer que toutes les users stories doivent être ready avant le début du sprint.
En procédant ainsi, vous perdez en agilité, et vous reproduisez ce que propose les méthodologies prédictives, à savoir : tout prévoir, tout estimer, tout planifier avant de commencer à travailler. - Spécifier toutes les user stories en sprint planning.
La definition of ready indique ce que doit être une user story prête à être développée. Mais ce travail peut être mené en corus de sprint. Pas nécessairement au début ou lors du sprint planning. - Rédiger une definition of ready sans concertation interne.
La defintion of ready est définie via un travail commun entre l'équipe de développement et le product owner. Quand je parle de travail commun, ce n'est pas "je décide de mon côté, et j'en informe l'autre". C'est vraiment une collaboration.
La definition of ready est-elle vraiment agile ?
Certains agilistes voient la definition of ready comme une contrainte, et comme quelque chose d'anti-agile hérité des méthodologies de gestion de projet traditionnelles.
C'est vrai qu'elle est souvent mal utilisée, notamment dans les équipes qui considèrent que les user stories doivent être en statut "ready" afin de passer dans la colonne "Todo" du sprint backlog. On l'a vu un peu plus haut.
Mais bien utilisé, la definition of ready peut apporter beaucoup de bonnes choses, et notamment de la qualité et une communication apaisée.
Alors, la definition of ready est-elle vraiment anti-agile ? Non, tant qu'on l'utilise comme cette pratique a été pensée à la base.
La definition of ready est même un bon atout pour l'agilité de l'équipe et la qualité et la valeur apportée.
Sinon Jeff Sutherland n'en aurait pas parlé dans cette vidéo :
Les bonnes pratiques pour gérer vos user stories
Vous souhaitez mieux spécifier vos user stories pour gagner en qualité sur votre projet ? C'est tout à votre honneur.
Voici les bonnes pratiques que vous pouvez mettre en place dès aujourd'hui :
- Construire une definition of ready la plus light possible.
Vous la ferez évoluer au fur et à mesure des sprints et des besoins qui émergent. - Acter la definition of ready d'un commun accord.
Le Product Owner ne la décide pas dans son coin, l'équipe de développement non plus. C'est un travail collaboratif. - Si ce qui est marqué dans la definition of ready n'a plus d'utilité, on cherche à comprendre pourquoi.
Et si après réflexion ça n'a vraiment plus d'utilité, alors on enlève, inutile de s'encombrer. - Rester ouvert au changement.
C'est le principe même de l'agilité. L'objectif de votre sprint est fixe, mais son périmètre est variable. On peut ajouter des user stories en cours de sprint dans le sprint backlog. - Découper de manière fine les user stories.
Un travail plus petit est plus simple à estimer et à réaliser dans un sprint. Cette notion devrait aparaître dans la definition of ready. - Spécifier les user stories que lorsque c'est réellement nécessaire.
Ni trop en amont, ni trop en retard. La spécification peut se faire lors du sprint planning ou encore durant le sprint. - Une user story n'est pas figée dans le marbre.
Elle peut être sujette à modifications enc ours de sprint ou au fur et à mesure de l'apprentissage de l'équipe. Une user story qui est détaillé selon la definition of ready peut tout à fait bouger dans le temps. - La definition of ready est une guideline, pas un jalon.
Une user story qui ne respecte pas encore la definition of ready ne doit pas bloquer le bon déroulement du projet ou du sprint. Restez agile, ne retombez pas dans les méthodes prédictives. - Planifier des ateliers pour spécifier les user stories.
Une user story de haute priorité ne correspond pas à la definition of ready ? Déclenchez un atelier de 30 minutes avec l'équipe de développement et le product owner afin de déterminer les critères d'acceptation. - Ajouter dans le Scrum board une colonne "Ready" en plus de la colonne "To do".
A une nuance près : la colonne "Ready" doit suivre la colonne "To do", et non pas l'inverse. n'oubliez pas : une user story peut être détaillée en cours de sprint, ce n'est pas un critère nécessaire pour l'intégrer au sprint backlog.
Gardez à l'esprit que la definition of ready est une invitation à la collaboration entre l'équipe de développement et le product owner.
Il ne s'agit pas d'un élément à agiter pour renvoyer le product owner dans les cordes comme sur un ring. S'il y a un problème de définition des user stories, ce point doit être soulevé lors des rétrospectives, afin que l'équipe Scrum au complet puisse trouver une solution.
