As-tu déjà pensé à ce que ta squad considère comme une bonne user story ? Si cette question te semble étrange, c’est que tu ne connais pas encore tous les bénéfices de la Definition of Ready ! Plus qu’une simple définition, cet article te permet d’être en mesure d’instaurer la Definition of Ready dans ton équipe et d’éviter les potentiels pièges.
Alors que la Definition of Done est définie et détaillée dans le Scrum guide, la Definition of Ready est encore à ce jour un terme peu / moins connu et moins intégré dans les équipes produits. La Definition of Ready liste de manière explicite les critères (établis par l’équipe) essentiels qui attestent qu’une user story est prête à être développée. Ici on parle de user story, mais certaines équipes l’appliquent à tous les items (Epic, US, Bug...) du Backlog ainsi qu'à un sprint afin de déterminer s'il est prêt à être commencé. Dans le Scrum guide, le Backlog Refinement est implicitement lié à la Definition of Ready.
Par conséquent, comme la Definition of Done, la Definition of Ready permet d’établir les critères auxquels une user story doit répondre pour passer d’un état à un autre (TO DO (DoR) ; DOING (DoD) ; DONE).
Il n’y a pas de liste définie applicable à toutes les équipes. C’est un travail continu entre le Product Owner / Product Manager et l’équipe de développeurs.
On a tous vécu une situation où les développeurs sollicitent le Product Owner car la user story n’est pas claire ou que les informations qu’ils cherchent ne sont pas présentes. D’autres exemples courants sont, en premier, la différence entre le résultat espéré par le Product Owner, qui a rédigé la user story, et l'interprétation des développeurs, ainsi que, l'écart important de l'estimation entre le sprint planning et le développement de la user story. Toutes ces situations peuvent être limitées / évitées en adoptant la Definition of Ready.
Par conséquent, la Definition of Ready permet :
Tu viens d’intégrer une nouvelle équipe ou commences une nouvelle mission, c’est le moment de l’établir ! La Definition of Ready (DoR) est avant tout un travail et une cohésion d’équipe dont les bénéfices sont visibles à court, moyen et long terme, car elle évolue en fonction de la maturité de l’équipe.
En premier, c’est le rôle du Product Owner / Product Manager d'entamer la conversation. Il est primordial qu’elle soit ouverte et bienveillante où chaque participant se sent en confiance pour parler et exprimer ses besoins / sa vision / ses attentes d’une bonne user story. Afin que la base de la Definition of Ready soit la plus cohérente, il est important d’inviter toutes les parties prenantes qui interagissent avec les user stories, que ce soit la rédaction, l’estimation, la réalisation ou la validation. Par exemple, dans une équipe, les personnes qui ont un point de contact avec les user stories sont : le Product Owner, l’UX manager, le Lead développeur, le Quality manager, le Scrum Master et les Développeurs.
Avant de commencer l’élaboration des critères, il est important d’expliquer les bénéfices de la Definition of Ready et répondre à toutes les questions. Il faut éviter à tout prix que ce nouveau “protocole” soit synonyme d’une contrainte ou d’un rituel en plus sans intérêt. De plus, il est essentiel de mentionner que les critères qui seront validés ne soient pas figés et qu’ils peuvent évoluer avec l’expérience. En moyenne, il est recommandé de revoir la Definition of Ready tous les 2 à 6 sprints.
Quand un climat de confiance est installé, en faisant un tour de table, chacun exprime qu’est-ce qu’une bonne user story à ses yeux et qu’est-ce qu’il attend y retrouver pour l’estimer et/ou la réaliser.
Par conséquent, à la fin de cette initiation, la première Definition of Ready doit :
Attention, dans une même équipe, souvent une équipe assez mature, en fonction des besoins ou des parties du produit, il peut avoir plus qu’une Definition of Ready ou des variations. Exemple, pour la partie front, la Definition of Ready doit inclure les wireframes alors que pour la partie Saas, l’architecture est primodiale.
Pour mieux comprendre l’évolution d’une Definition of Ready pour une user story et pour un Sprint, voici 2 exemples concrets :
DoR V1
DoR V2
DoR V3
Dans notre exemple, nous ajoutons de nouveaux critères, mais n’hésites pas aussi à te poser la question si les éléments présents dans la Définition of Ready sont utiles (exemple wireframes et requis design) et aident les parties prenantes en fonction de l’état de la user story.
Tips : pour plus de visibilité sur le niveau d’affinage des user stories présentes dans le Backlog produit, n’hésitez pas à ajouter un code couleur comme par exemples, rouge – orange - vert ou bronze - argent – or
Comme précisé plus haut, la Definition of Ready peut aussi s’appliquer au sprint en listant les critères qui permettent de s’assurer qu’il ne manque rien.
Par exemple, la DoR d’un sprint peut comprendre :
Par conséquent, la Definition of Ready est un outil utile pour se poser des questions et s’assurer qu’on n'a pas oublié quelque chose.
Dans la définition qui introduit cet article, nous mentionnons que la Definition of Ready représente les critères essentiels pour certifier qu’une user story est éligible à être développée. Nous n'avons volontairement pas mentionné que la Definition of Ready est un critère pour qu’une user story soit embarquée dans un sprint. En effet dans un monde idéal, toutes les user Stories sont finalisées lors du Backlog Refinement et les user stories remplissent tous les critères de la DoR avant le sprint. Néanmoins, il ne faut pas être rigide et par conséquent impacter l’agilité de son équipe. La DoR doit rester une ligne directrice de référence et non un état indispensable.
Par exemple, lors du Backlog Refinement, il peut manquer une partie des requis design ou technique, mais tant que la user story est comprise par tous et que les critères essentiels sont présents, l’équipe peut la présenter au sprint planning. De plus, notre exemple, montre l’ajout progressif de critères. Attention, la Definition of Ready, ne doit ni être une liste à rallonge de critères qui sont peu ou pas utiles à l’équipe et elle ne doit pas faire perdre du temps au Product Owner lors de sa rédaction. Par conséquent, comme le sprint Backlog, la Definition of Ready est variable. Le scope agile est variable, certains éléments qui seront développer en fin de sprint peuvent être embarqués et être finalisés au cours du sprint. L’important dans un sprint est de réaliser l’objectif du sprint.
Pour conclure, la Definition of Ready est un outil indispensable pour aligner l’équipe sur les attentes de chacun, de gagner du temps et limiter les frustrations. En instaurant la Definition of Ready et la Definition of Done au sein de ton équipe, tu gagneras en vélocité et par conséquent, tu augmenteras la création de valeur pour les utilisateurs et le business.
Ce qu’il faut retenir :
Le spécialiste du conseil fullstack Produit : Strategy, Discovery & Delivery !
