Definition of done vs Definition of ready : quelles différences ?

Table des matières

Les méthodes agiles, et plus particulièrement Scrum, mettent l’accent sur la valeur apportée aux clients et sur la qualité. Et pour cela, il existe deux notions très intéressantes : la definition of ready et la definition of done.

Comment les utiliser ? Et quelles sont les différences ?

Voyons cela ensemble.

Qu’est-ce que la definition of done ?

La definition of done, ou DoD, est une checklist de critères à vérifier permettant de s’assurer qu’une user story est réalisée à 100% dans un contexte agile. Cette pratique permet d’assurer un niveau d’exigence de qualité minimum tout au long du projet.

Dans un contexte agile, l’équipe ne s’engage pas sur une quantité de travail à effectuer (le nombre d’items intégrés au sprint backlog). Elle s’engage sur ce que signifie un incrément de qualité via cette definition of done.

Elle évolue au fur et à mesure des itérations et des besoins qui émergent. Elle est mise à jour lors des rétrospectives de l’équipe Scrum.

Pour aller + loin : Qui rédige la definition of done ? Quand faut-il la créer ou la mettre à jour ? Comment la gérer lorsqu’on a plusieurs équipes ? Je réponds à vos questions sur la definition of done ici.

Qu’est-ce que la definition of ready ?

La definition of ready, ou DoR, est une liste d’éléments qui définissent la qualité attendue par l’équipe afin de commencer le développement d’une user story dans les projets agiles. Cette liste prend généralement la forme d’une checklist à valider.

Tout comme la definition of done, la definition of ready contribue à maintenir un haut standard de qualité durant le projet. Elle permet également la facilitation de la communication entre l’équipe de développement et le product owner.

Elle assure également une compréhension commune de ce que signifie une user story prête à être développée, et une user story de qualité.

C’est un levier pour améliorer la qualité de vos user stories. Elle est ainsi complémentaire à la definition of done, qui permet d’assurer un haut niveau de qualité des incréments (le travail livré à la fin du sprint).

Pour aller + loin : Qui rédige la definition of ready? Quand faut-il la créer ou la mettre à jour ? Quelle est son origine et est-elle vraiment agile ? Je réponds à vos questions sur la definition of ready dans cet article.

Definition of done vs Definition of ready

Maintenant que l’on a vu ce qu’est la définition de fini (definition of done) et définition de prêt (définition de ready), voyons ensemble les principales différences qui existent entre ces deux notions :

CritèresDoR – Définition of ReadyDoD – Definition of Done
DescriptionListe d’éléments qui définissent la qualité attendue par l’équipe afin de commencer le développement d’une user story.Liste contextuelle de critères à vérifier, permettant de s’assurer qu’un travail est réalisé à 100% et est prêt à être livré au client.
UsageAméliore la qualité de rédaction et de spécification des récits utilisateurs (user stories)Définit le niveau d’exigence de qualité minimum que l’équipe doit respecter pour ses incréments de sprint
ConcerneLes items du product backlog (user stories)Le travail à réaliser en cours de sprint (user stories dans le sprint backlog)
ContenuBonnes pratiques à suivre dans la rédaction et la spécification des user stories (commun pour tous)Critères d’achèvement (commun pour tous) + Critères d’acceptation (propre à chaque user story)
Artefact et EngagementArtefact de transparence officieux.Poussé par Jeff Sutherland, co-créateur de Scrum.Artefact de transparence. Engagement lié à l’incrément.
Décrit dans le guide ScrumNonOui
Garant et ResponsabilitésÉquipe de développement + Product Owner Équipe de développement + Product Owner
Quand la créerIdéalement le 1er sprint, mais reste optionnelAvant le 1er sprint
ÉvolutivitéOui, peut et doit évoluer au fur et à mesure des itérationsOui, peut et doit évoluer au fur et à mesure des itérations
Fréquence de mise à jourA chaque fois que nécessaire. La question doit être posée à la fin de chaque sprint.A chaque fois que nécessaire. La question doit être posée à la fin de chaque sprint.
Quand mettre à jourIdéalement pendant la rétrospective.Peut être fait en cours de sprint si nécessaire.Pendant la rétrospective uniquement. Ne doit jamais être mis à jour en cours de sprint.

Exemples de critères de la definition of done

Vous trouverez ci-dessous les critères les plus courants qui apparaissent dans la definition of done. J’attire votre attention sur le fait que cette liste n’est pas exhaustive, vous pouvez y ajouter vos propres critères.

Il y a cependant un critère qui devrait apparaître dans toutes les definition of done, toutes équipes confondues : « les critères d’acceptation de la user story sont respectés ».

  • Le développement est terminé.
  • Les tests unitaires sont réalisés et sont OK.
  • Le code a été revu par un autre programmeur.
  • La qualité s’améliore.
  • La dette technique diminue.
  • Les maquettes graphiques sont respectées.
  • Les pages du site web se chargent en moins d’une seconde.
  • L’intégration continue fonctionne.
  • L’incrément est utilisable sur un environnement de test.
  • La documentation est écrite.
  • L’application de démo est disponible.
  • La recette de la fonctionnalité a été effectuée par l’équipe.
  • Les critères d’acceptation de la user story sont respectés.

Pour aller + loin : Dans cet article, je vous livre 11 conseils d’experts afin de construire une bonne definition of done avec votre équipe.

Exemples de critères de la definition of ready

Voici quelques critères qui peuvent apparaître dans la definition of ready. Bien sûr il ne s’agit pas d’une liste exhaustive, et vous pouvez très bien ajouter vos propres critères :

  • Un titre explicite.
  • Une description ou une proposition de valeur, la plupart du temps formulée comme ceci : « En tant que [..], je peux […] afin de […]. »
  • La user story est compréhensible et réalisable.
  • La user story est testable.
  • La user story a des critères d’acceptation de définis.
  • Les dépendances sont identifiées, s’il y en a.
  • L’estimation a été réalisée par l’équipe de développement.
  • Les critères de scalabilité, performance et sécurité sont détaillés si nécessaire.
  • Un jeu de données de tests fourni à l’équipe.
  • Une maquette est fournie.

Pour aller + loin : Étant donné que la definition of ready n’est pas décrite officiellement dans le Scrum Guide, cette notion est-elle vraiment agile ? Réponse dans l’article.

Critères d’achèvement vs Critères d’acceptation : Quelles différences ?

Il existe deux types de critères qui permettent de définir la qualité d’un travail :

  • Les critères d’achèvement.
    Ils représentent les critères à respecter pour qu’un travail soit terminé à 100%. C’est ce qu’on appelle communément la definition of done, ou définition de fini. Ils s’appliquent à l’ensemble des éléments du backlog.
  • Les critères d’acceptation.
    Ils sont uniques et associés à une seule user story. Ils indiquent les conditions de satisfaction métier qui permettent de satisfaire l’utilisateur. Un critère d’achèvement sur la definition of done peut être de respecter tous les critères d’acceptation de la user story.

Allons un peu plus loin, et analysons ensemble les différences qui

Image de Thibault Baheux

Thibault Baheux

Tour à tour chef de projet puis manager d'équipe depuis 2008, je suis aujourd'hui directeur de projet indépendant. J'ai décidé via ce site de démocratiser la gestion de projets et de la rendre accessible à tous. Mes certifications : Prince2 Foundation, CompTIA Project+ certified, PSM1, PSPO1, Lean Six Sigma Black Belt.

Devenez un chef de projet performant

Et recevez dans votre boîte mail un exemplaire du guide « 15 facteurs-clés pour réussir vos projets ».

Ce guide est un condensé de conseils pratiques, tirés de mes 14 années d’expérience en pilotage de projets.