DoR DoD : Definition Of Ready, Definition Of Done,DOR et DOD, concepts de SCRUM

DoR, DoD : des concepts qui viennent de SCRUM

En tant que Product Owner (PO), l’équipe et moi-même devons avoir une définition claire de READY (DoR) et DONE (DoD) pour dépiler les users stories du backlog rapidement et efficacement.

Product Owner : maître du jeu du backlog produit
Product Owner :  maître du jeu du backlog produit

Un des ateliers qui reste plus que nécessaire pour une nouvelle équipe AGILE est le DoR / DoD. Ce sont des concepts qui viennent de SCRUM.

Quelque soit le framework ou méthodologie utilisé(e), il y aura toujours le représentant du produit (dans SCRUM le Product Owner ou PO). Le PO est le meneur de jeu du backlog produit.

Definition of Ready

Les user stories figurant en haut du backlog produit (priorisées par le PO par valeur commerciale ou métier) que l’équipe va intégrer dans le backlog sprint doivent être prêtes :

  • état exploitable, faisable, testable,
  • estimées plus ou moins à la bonne taille.

Ces user stories seront sélectionnées par l’équipe lors du sprint planning. Le Definition Of Ready ou DoR représente un ensemble de critères pour qu’une user story soit « sélectionnable » par l’équipe dans un sprint.

Definition of Done

Le DoD garantit que tout le monde dans l’équipe (PO compris) sait exactement ce qui est attendu. Il assure la transparence et la qualité du produit. Le Definition Of Done représente l’ensemble des critères pour qu’une user story soit dîtes « Terminé. Candidat pour la prod ! ».

Objectifs de l’atelier

  • L’équipe doit être en mesure de déterminer ce qui doit être fait et la quantité de travail requise pour compléter la user story.  Les user stories « READY » doivent être claires, concises et surtout réalisables.
  • L’équipe doit comprendre les critères « DONE » et les exigences qui seront à vérifier pour démontrer que la user story est « Terminé. Candidat pour la prod ! ».

Déroulement de l’atelier

Cet atelier s’effectue en présence du PO, de l’équipe (Développeurs, Testeurs, Spécificateurs…) et certains managers.

En ce qui me concerne, j’interviens en tant que facilitateur. Je reprends alors sur le support mural de la salle le workflow JIRA utilisé actuellement sur le projet :

  • Open : la user story est dans le backlog produit.
  • Specification : la user story est dans le backlog de sprint et en cours de spécification. Elle pourra être associée à plusieurs tâches.
  • Specified : spécification terminée mais cela n’empêche pas de revenir là dessus après une session de refinement par exemple !
  • Development : la tâche ou la user story est en cours de développement.
  • Delivered : la tâche ou la user story  est en cours de validation par les équipes de test.
  • Done : User story « Terminé ! Candidat pour la prod » ainsi que toutes les tâches associées. Tous les « Done » peuvent être potentiellement envoyés en Production.

Le but est de laisser les participants (surtout le PO et l’équipe) définir la liste des critères et des exigences pour qu’une user story (sans descendre au niveau des tâches) passe d’une étape à une autre dans le workflow actuel.

Quelques exemples de critères définis suite à l’atelier :

User Story Ready for « Specification »

  • Réalisable
  • Priorisée par le PO
  • Estimée par l’équipe de réalisation (Développeurs, Testeurs …)

User Story Ready for « Development »

  • Spécifiée en utilisant le template défini par l’équipe (dans un autre atelier)
  • Scénarios de test fonctionnels décrits avec tous les paramètres d’entrées (fichiers, texte, formules…. ) et les résultats attendus

User Story Ready for « Test » (Delivered)

  • Développé
  • Revue de code
  • Test unitaires et d’intégration faits et vérifiés
  • Scénarios de test fonctionnels automatisés faits et vérifiés avec le testeur

User Story Done

  • Tests unitaires, intégration et fonctionnels validés dans la pipeline 
  • Démo effectuée et validée
  • Release Note à jour
  • Documentation technique et fonctionnelle à jour

Par ailleurs, il est également nécessaire que les rôles et responsabilités de chacun autres que ceux de SCRUM (via par exemple un atelier RACI) soient clairement définis pour mener à bien ces différentes tâches !