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

Thibault Baheux

26 novembre 2022 - minutes de lecture

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ères

DoR - Définition of Ready

DoD - Definition of Done

Description

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

Usage

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

Concerne

Les items du product backlog (user stories)

Le travail à réaliser en cours de sprint (user stories dans le sprint backlog)

Contenu

Bonnes 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 Engagement

Artefact 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 Scrum

Non

Oui

Garant et Responsabilités

Équipe de développement + Product Owner 

Équipe de développement + Product Owner

Quand la créer

Idéalement le 1er sprint, mais reste optionnel

Avant le 1er sprint

Évolutivité

Oui, peut et doit évoluer au fur et à mesure des itérations

Oui, peut et doit évoluer au fur et à mesure des itérations

Fréquence de mise à jour

A 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 à jour

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

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 existent entre les critères d'achèvement (la definition of done) et les critères d'acceptation (uniques pour chaque user story)

 

Critères d'achèvement

Critères d'acceptation

Description

Indique ce qui doit être fait pour qu'une user story soit terminée (tests, documentation, etc...)

Indique les conditions de satisfaction métier d'une user story qui permettent de satisfaire l'utilisateur

Usage

Commune à tous les éléments du backlog.

Unique pour chaque user story.

Garant et responsabilité

L'équipe de développement est garante et responsable de la definition of done.

Le Product Owner est garant des critères d'acceptation.

Évolutivité

Peut évoluer en rétrospective.

Sont négociés au moment de la rédaction d'une user story.

Qualité

La definition of done garantit le respect des critères d'acceptation, en plus d'autres éléments.

Le respect des critères d'acceptation ne garantit pas le respect de la definition of done.


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, Lean Six Sigma Yellow Belt.


Articles Similaires


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}