Définition de fait vs critères d’acceptation dans Scrum – Guide complet

Définition de fait (DoD) est une liste de contrôle des exigences que doit remplir une histoire utilisateur pour que l’équipe la considère comme terminée. Alors que le critères d’acceptation d’une histoire utilisateur inclut un ensemble de cas de test qui doivent être remplis pour confirmer que le logiciel fonctionne comme prévu.

La différence principale réside dans le fait que le DoD est commun à toutes les histoires utilisateur, alors que les critères d’acceptation sont spécifiques à chaque histoire utilisateur. Les critères d’acceptation de chaque histoire utilisateur varieront selon les exigences spécifiques de cette histoire.

Autrement dit, les deux la Définition de fait et les critères d’acceptation doivent être remplis pour qu’une histoire utilisateur soit considérée comme complète. L’incrément produit n’est pas considéré comme complet à moins que les deux listes de contrôle soient entièrement satisfaites. Par conséquent, nous devons définir deux aspects de la Définition de fait : le DoD et les critères d’acceptation :

Définition de fait vs critères d’acceptation

Définition de fait :

La Définition de fait est structurée comme une liste de contrôle, chaque élément servant de point de vérification pour une histoire ou un PBI. Son objectif est de garantir que l’équipe de développement est d’accord sur la qualité du travail qu’elle livre. Elle agit comme une liste de contrôle pour vérifier l’achèvement de chaque Product Backlog élément (également connu sous le nom de PBI ou histoire utilisateur). Les éléments de la Définition de fait sont destinés à s’appliquer à tous les éléments du Product Backlog, et non seulement aux histoires utilisateur individuelles. Elle peut être résumée comme suit :

• S’applique à l’ensemble de l’incrément produit
• Implique que l’incrément produit est potentiellement livrable dans la plupart des cas
• Défini dans le guide Scrum
• Sert d’outil de communication entre les membres de l’équipe :
  • Qualité globale du logiciel
  • Si l’incrément est livrable

Objectifs de la Définition de fait

• Établir une compréhension partagée de la qualité et de l’achèvement au sein de l’équipe
• Agir comme une liste de contrôle pour vérifier les histoires utilisateur (ou les PBIs)
• S’assurer que l’incrément produit à la fin d’un Sprint est de haute qualité et que tous les participants comprennent clairement les normes de qualité

Exemple – Définition de fait

Par exemple, dans l’industrie logicielle, les équipes peuvent poser les questions suivantes pour définir leur DoD :

• Code revu par les pairs ?
• Code terminé ?
• Code revu ?
• Code vérifié ?
• Les tests unitaires ont réussi ?
• Les tests fonctionnels ont réussi ?
• Les tests d’acceptation sont terminés ?
• Le propriétaire produit a revu et accepté

Critères d’acceptation

Une histoire utilisateur est l’un des principaux artefacts dans le développement agile, mais Scrum ne requiert pas explicitement l’utilisation d’histoires utilisateur ou de critères d’acceptation. Si un élément du backlog produit est trop volumineux pour tenir dans un Sprint, il est généralement décomposé en histoires utilisateur, puis en une série de tâches, comme indiqué ci-dessous :

Critères d’acceptation

Les histoires utilisateur intègrent les critères d’acceptation, c’est pourquoi nous voyons souvent le « Définition de fait » et les critères d’acceptation coexister dans nos processus Scrum. L’histoire utilisateur fournit le contexte pour la fonctionnalité que l’équipe doit livrer. Les critères d’acceptation fournissent des indications détaillées sur ce que la fonctionnalité doit faire et comment le client l’acceptera. Ensemble, ils définissent la livraison complète.

Certains critères d’acceptation sont découverts lors des sessions continues de révision du backlog avant le début du Sprint, tandis que d’autres sont identifiés immédiatement après la planification du Sprint, afin que l’équipe puisse avoir une conversation autour de l’histoire utilisateur. Par conséquent, les critères d’acceptation constituent une caractéristique unique d’une histoire utilisateur ou d’un élément du backlog produit.

• S’applique à chaque PBI/histoire individuelle
• Les critères d’acceptation varient selon chaque PBI/histoire
• Non définis dans le guide Scrum
• Sert d’outil de communication pour répondre aux exigences spécifiques d’un PBI/histoire
• Également connus sous le nom de tests d’acceptation, conditions de satisfaction, ou dans certains cas « cas de test »

Objectifs des critères d’acceptation

• Préciser ce que l’équipe doit établir avant de commencer le travail
• S’assurer que tout le monde partage une compréhension commune des exigences
• Aider les membres de l’équipe à comprendre quand une histoire est terminée
• Aider à vérifier l’histoire grâce à des tests automatisés

Exemple – Critères d’acceptation

• L’utilisateur ne peut pas soumettre le formulaire sans remplir tous les champs obligatoires
• Les informations du formulaire sont stockées dans la base de données d’inscription
• Les invités peuvent payer par carte de crédit
• Un e-mail de confirmation est envoyé à l’utilisateur après soumission du formulaire

Exemple d’une histoire d’utilisateur avec des critères d’acceptation

L’image ci-dessous montre un exemple de critères d’acceptation pour une histoire d’utilisateur.

Exemple de définition de terminé