Comprendre les Critères d’Acceptation et la Définition of Done en Scrum : Le Savoir-Clé de l’Agilité »
Dans mes récentes interactions, j’ai réalisé que de nombreux professionnels sont souvent perplexes quant à la distinction entre les Critères d’Acceptation et la Definition de « Done ». Une conversation intéressante a eu lieu lors de ma dernière formation de Scrum Master à Paris, et voici comment cela s’est déroulé :
Question : Quand pouvons-nous considérer un élément du Backlog Produit comme Fini ?
Ma réponse : Lorsqu’il répond à la « Definition of Done ».
Question : Je pensais que cela avait à voir avec les critères d’acceptation.
Ma réponse : Oui, vous avez raison.
Question : Mais vous avez dit « Definition of Done ».
Ma réponse : Oui, la Definition of Done garantit également que vous respectez les Critères d’Acceptation.
Question : Ne sont-ils pas la même chose ?
Ma réponse : Non, ils ne le sont pas, ils servent à des fins différentes.
Cette interaction m’a poussé à rédiger ce blog où je m’efforce de clarifier l’importance de la Definition of « Done » (DoD) et des Critères d’Acceptation.
La plupart des équipes agiles utilisent les user stories comme un instrument pour découvrir les besoins, considérant la user story comme un rappel pour engager des discussions au bon moment.
Lorsque nous discutons de la user story, nous identifions les éléments nécessaires pour que cette US réponde aux attentes du métier. L’équipe de développement comprend les user stories en comprenant ces éléments, appelés Critères d’Acceptation.
Les discussions typiques sur les user stories peuvent commencer avec le métier disant qu’il a besoin de la possibilité de rechercher un livre, et la user story peut être rédigée comme suit : « En tant que lecteur de livres, je souhaite rechercher un livre afin de trouver un livre intéressant. »
Lorsque le développeur examine cela, il a besoin de plus de détails sur les critères de recherche possibles qui peuvent aider le lecteur à trouver un livre intéressant. Ces critères sont identifiés en discutant de la user story avec le Product Owner, et vous obtenez finalement des critères tels que :
- L’utilisateur doit pouvoir rechercher par auteur.
- L’utilisateur doit pouvoir rechercher par titre de livre.
Nous avons maintenant identifié les Critères d’Acceptation. De la même manière, nous faisons la même chose pour chaque élément du backlog produit, ou plutôt chaque user story dans le backlog produit.
Lorsque le développeur commence à travailler dessus, il peut terminer le développement en respectant à la fois les critères d’acceptation et informer le Product Owner qu’il a terminé son travail. Le Product Owner peut devenir enthousiaste et ouvrir l’instance qu’il possède, puis réaliser que cela a été terminé sur sa machine et non sur l’instance qu’il regarde.
Lorsque le Product Owner demande quand il pourra le voir sur son instance, il peut découvrir que cela prendra quelques jours. Pour éviter toute incompréhension de la notion de « Fini », dans Scrum, nous créons une « Definition of Done DoD ». La Definition of Done aide l’équipe Scrum à avoir une compréhension commune partagée de l’achèvement des éléments du Backlog Produit.
La Definition of Done comprend un ensemble convenu d’items que chaque élément du Product backlog doit respecter avant d’être considéré comme Fini. Nous ne créons pas une DoD séparée pour chaque élément du Product Backlog, mais elle s’applique uniformément à tous les éléments du Backlog de produit, en plus des Critères d’Acceptation propres à chaque élément. Voici quelques points qui constituent la Definition of Done :
- Code avec revue par les pairs.
- Code fusionné dans la branche principale (Main branch).
- Réussite des tests automatisés.
- Aucun défaut ouvert devant être corrigé.
- Tests effectués sur Chrome et IE.
- Tous les Critères d’Acceptation validés avec des données de test convenues.
Les différences entre les Critères d’Acceptation et la Definition of Done :
Definition of Done | Acceptance Criteria (conditions de satisfaction pour une User Story) |
Elle sert à établir une compréhension non ambiguë de tout ce qui est nécessaire avant que n’importe quel élément du Product Backlog puisse être déclaré complet. | Ils servent à clarifier les besoins métiers ou les conditions qui doivent être remplies pour satisfaire l’utilisateur pour un besoin donné. |
Elle s’applique uniformément à tous les éléments du Backlog Produit. | Ils s’appliquent à un élément spécifique du Product Backlog, car ils clarifient cet élément. |
L’équipe de développement est responsable de la Définition of Done, et elle est comprise et acceptée par l’ensemble de l’équipe Scrum. | Le Product Owner est responsable des Critères d’Acceptation, et l’équipe de développement les comprend. |
La Définition of Done ne change pas fréquemment, elle n’est pas censée changer pendant le sprint. | Les Critères d’Acceptation sont négociables entre le Product Owner et l’équipe de développement. |
Respecter la DoD garantit le respect des Critères d’Acceptation. | Se contenter de respecter les Critères d’Acceptation ne signifie pas nécessairement que la Definition of Done est également respectée. |
En Conclusion :
Les Critères d’Acceptation sont les conditions de satisfaction que le Product Owner indique lorsqu’il demande un besoin particulier; tandis que la Defintion of Done comprend des conditions qui doivent être respectées pour tous les besoins et éléments du Product Backlog. En tant que développeur, j’identifie le travail nécessaire pour respecter les Critères d’Acceptation et la Definition of Done DOD lors de la réunion de planification du sprint (Sprint Planning), afin de répondre aux attentes du Product Owner et du reste de l’équipe.
J’espère vraiment que ce blog vous aide à comprendre la différence entre les Critères d’Acceptation et la Définition of « Done ».
Si vous souhaitez devenir un Praticien Agile Certifié, nous proposons un programme en ligne complet qui rend les concepts plus accessibles et vous aide à obtenir rapidement votre certification.
Pour clarifier d’avantage la différence entre les Critères d’Acceptation et la DoD, Il est temps de passer à l’action et de saisir cette opportunité de vous former avec CertiSkills. N’hésitez plus et réservez dès maintenant votre place pour nos formations 100% en ligne. Pour toute information supplémentaire, n’hésitez pas à nous contacter au (+33) 6-29-37-62-76 ou par e-mail à contact@certiskills.fr et Envisagez de rejoindre notre programme de formation Professionnel Scrum master.