Aller au contenu

Comment établir la Definition of Ready (DoR) ?

Avez-vous déjà pensé à ce que votre squad considère comme une bonne User Story ? Si cette question vous semble étrangec’est que vous ne connaissez pas encore tous les bénéfices de la Definition of Ready ! Plus qu’une simple définition, cet article vous permet d’être en mesure d’instaurer la Definition of Ready dans votre équipe et d’éviter les potentiels pièges.  

Sommaire

Qu’est-ce que la Definition of Ready (DoR) ?

Une courte définition de la DoR

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 permettent 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. 

Les avantages à mettre en place la DoR

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ésentesD’autres exemples courants sont, en premier, la différence entre le résultat espéré par le Product Ownerqui a rédigé la User Storyet 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 :  

  • Aligner toute l’équipe sur les besoins de chacun ;
  • Unifier / standardiser les User Stories pour donner des repères à l’équipe ;
  • Simplifier la rédaction des User Stories ;
  • Améliorer la qualité des User Stories, gagner en maturité et limiter les oublis et futurs bugs en étant plus rigoureux ;
  • Limiter les rituels à rallonge (sprint planning) ;
  • Simplifier la collaboration et les phases de développement ;
  • Maximiser les chances d’atteindre l’objectif du sprint en améliorant la prédictibilité (estimation plus fine / fiable).  

Comment construire la Definition of Ready ?

La mise en place de la Definition of Ready

Vous venez d’intégrer une nouvelle équipe ou commencez 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 sont 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 réaliser la User Story. 

Par conséquent, à la fin de cette initiation, la première Definition of Ready doit : 

  • Être définie de manière explicite afin que toute l’équipe comprenne les points indispensables d’une User Story et que chacun soit d’accord avec la première version de la Definition of Ready.
  • Elle doit inclure au minimum les critères suivants :
    • La valeur (utilisateur / business) attendue qui permet au Product Owner de la prioriser ;
    • Les requis techniques, voire les wireframes en fonction du produit ;
    • Respecter les 5 critères d’une bonne User Story selon l’acronyme INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).

       

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. 

definition of ready liste

Exemple de l’évolution d’une Definition of Ready

Pour mieux comprendre l’évolution d’une Definition of Ready pour une User Story et pour un Sprint, nous vous donnons 2 exemples concrets :   

DoR V1 DoR V2 DoR V3
  • Un titre clair
  • Une courte description
  • La définition de valeur attendue
  • Un critère d’acceptance
  • Une estimation
  • Un titre clair
  • Une courte description
  • La définition de valeur attendue
  • Plusieurs critères d’acceptance
  • Une estimation
  • Les objectifs mesurables (KPI)
  • Les Wireframes
  • Un titre clair
  • Une courte description
  • La définition de valeur attendue
  • Plusieurs critères d’acceptance
  • Une estimation
  • Les objectifs mesurables (KPI)
  • Les Wireframes
  • Les règles métiers
  • Les requis techniques
  • Les requis design
  • Les dépendances à la User Story 
  • L’explication pour réaliser la démo

Dans notre exemple, nous ajoutons de nouveaux critères, mais n’hésitez pas aussi à vous 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.  

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 :  

  • Le sprint Backlog est priorisé ;  
  • Le sprint Backlog comprend tous les éléments que l’équipe a accepté d’embarquer pour le prochain sprint ;  
  • Il n’y a pas de travail dissimulé ;  
  • Chaque membre a calculé sa capacité pour le sprint ;  
  • Le temps total du sprint = X heures / jour ;  
  • Toutes les US répondent aux critères de DoR.
     
     

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.

Les dangers de la Definition of Ready

Dans la définition qui introduit notre 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. 

Sprint planning

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 votre équipe, vous gagnerez en vélocité et par conséquent, vous augmenterez la création de valeur utilisateur et business. 

Ce qu’il faut retenir :  

  •  La Definition of Ready (DoR) détermine la qualité des User Stories qui sont présentées aux développeurs et les critères qui les rendent éligibles développées durant un sprint.  
  • La DoR est le fruit d’une conversation ouverte entre toutes les parties prenantes dans l’élaboration, estimation, réalisation et validation des User Stories (PO /PM, UX, DEV, QA…) 
  • La DoR n’est pas figée dans le temps et est revue tous les 2 à 6 sprints en fonction de la maturité de l’équipe.  
  • Les principaux avantages de la DoR sont : optimiser la rédaction, l’estimation, la réalisation ainsi que gagner du temps lors du sprint planning.  
  • La DoR ne remplace pas les autres rituels comme les 3 amigos ou le sprint planning.