Comment définir la Definition of Ready (DOR)

7
minutes de lecture

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.  

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

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é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 :  

  • 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 (DOR) ?

La mise en place de la Definition of Ready

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 :  

  • Ê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.  

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, voici 2 exemples concrets :    

DoR V1

  • Un titre clair
  • Une courte description
  • La définition de valeur attendue
  • Un critère d’acceptance
  • Une estimation

DoR V2

  • 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

DoR V3

  • 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é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 :  

  • 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 (DOR)

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 :  

  • 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
Logo WeFiiT

Le spécialiste du conseil fullstack Produit : Strategy, Discovery & Delivery !

Auteur

Jéromine

Product Owner