Ce que « Done » signifie vraiment ?

La ‘Definition of Done’ est un sujet très populaire qui amène régulièrement des débats animés au sein des équipes agiles. Parmi les Agile Practitioner, chacun a son avis sur le sujet allant de « ça dépend » à « il faut laisser les équipes décider » en passant par l’utilisation d’un ensemble de critères rigoureusement prédéfinis prenant en compte tous les scénarii possibles. Et à mesure que les organisations adoptent les pratiques agiles, je vois apparaître au cours de mes missions de coaching agile des confusions dans la compréhension de la signification de ‘Done’.

L’une des raisons de cette complexité est que le mot ‘Done’ est trop utilisé. Il peut, en effet, être appliqué à différents niveaux comme la User Storie, l’EPIC, la release ou le produit avec à chaque fois des critères différents pour déterminer le ‘Done’. Pour cette

La seconde raison est le point depuis le quel on observe la scène. Si on regarde d’un peu plus près ce que signifie ‘Done’ pour une User Story, nous remarquons qu’il est souvent utilisé par l’équipe pour signifier ‘complété’ ou ‘achevé’ au sens de : « nous avons terminé de travailler sur cette User Story ». Mais il sert également au Product Owner pour indiqué ‘accepté’ au sens de : « Cette User Story est terminée ». Lorsque j’accompagne des équipes vers plus d’agilité, je leur recommande de ne pas utiliser le mot ‘Done’ mais d’employer plutôt les termes ‘complété’ et ‘accepté’ pour gagner en précision sur les statuts.

Nous pouvons alors définir deux aspects de la Definition of Done :

  • les critères d’achèvement (Completion Criteria),
  • les critères d’acceptation (Acceptance Criteria).

Le tableau ci-après décrit les principales différences entre ces deux notions.

Les critères d’achèvement

Les critères d’achèvement représentent ce qu’on appelle classiquement la ‘Definition of Done’ telle que la définit le Scrum Guide. Ces critères peuvent être résumés comme suit :

  • « Code écrit » – tel que défini par l’organisation / les équipes
  • « Testé » – tel que défini par l’organisation / les équipes
  • « Revu par les pairs » (qualité) – tel que défini par l’organisation / les équipes
  • « Aligné avec les attentes » – telle que défini par l’organisation / les équipes
  • « Documenté » (selon les besoins, déterminé par l’équipe Scrum au début de Sprint)

L’équipe Scrum (Equipe de Dev + PO + SM) détermine la liste des critères d’achèvement qui doivent être respectés, avec l’aide du ScrumMaster, pour déterminer qu’une User Story puisse être considérée comme terminée. Cette liste est donc valable pour l’ensemble des User Stories qui composent le Product Backlog. Pour savoir comment organiser un atelier de Definition of Done, référez-vous à cet article.

Cette approche fournit un cadre modulaire et adaptable permettant à chaque équipe de personnaliser leurs définitions pour tenir compte de leurs spécificités propres. Chaque groupe de critères pourra être détaillé en éléments unitaires plus fins

Au quotidien, c’est l’équipe de développement qui s’assure que l’ensemble des critères d’achèvement ont été respectés. La User Story est alors considérée comme « complété » (ou achevée).

Les critères d’acceptation

Les critères d’acceptation peuvent être caractérisés comme suit :

  • La liste des attentes pour une User Story tel que défini par le Product Owner avant le début d’un sprint,
  • Le Product Owner peut préalablement les définir seul mais finit souvent par solliciter l’aide de l’équipe de développement et du ScrumMaster,
  • Pour les cas où les critères d’acceptation ne sont pas clairs, un Spike sera utilisé pour définir le problème et les critères d’acceptation pour une User Story qui sera réalisée dans un Sprint futur,
  • Toute l’équipe Scrum doit être en accord avec ces critères d’acceptation à l’issue de la réunion de planification de Sprint,
  • Des modifications mineures peuvent être apportées aux critères d’acceptation une fois que le Sprint est en cours dès lors qu’il existe un accord formel entre l’équipe de développement, le ScrumMaster et le Product Owner,
  • Lorsque l’équipe de développement pense que ces critères d’acceptation ont été respectés, la User Story est prête pour une revue par le Product Owner démo) ; des mini-démos ont donc lieu tout au long du sprint,
  • La revue (démo) de chaque User Story ne doit pas être repoussée jusqu’à la fin du sprint, en d’autres termes le Product Owner ne doit pas découvrir le travail fait par l’équipe lors de la Revue de Sprint (Sprint Review).

C’est le Product Owner qui détermine les critères d’acceptation pour chaque User Story et décide officiellement lorsque ces critères d’acceptation ont été respectés. La User Story est alors considérée comme « acceptée ».

Remise en contexte

Le tableau ci-dessous illustre comment peut être utilisée la Definition of Done au cours des différents moments de vie du Sprint.

La première colonne du tableau définit l’activité Scrum pendant laquelle l’action mentionnée dans la colonne 2 a lieu. La colonne 3 identifie quel(s) rôle(s) sont principalement responsables de l’action.

Pour les équipes que j’ai pu accompagner, au sein desquelles la relation entre le Product Owner et l’équipe de développement pouvait parfois être conflictuelle, ce diagramme a permis de clarifier les responsabilités. En combinaison avec une ‘Definition of Done’ claire, cela permet de réduire certaines tensions.

Chaque organisation (ou équipe) doit parvenir à un consensus sur ce que signifie ‘Done’ pour leurs projets / produits en particulier, à différents niveaux (User Story, Feature, Sprint, Release, etc.).

Vous aimerez aussi...

3 réponses

  1. 12 avril 2019

    […] Si tu souhaites en savoir plus, lis cet article. […]

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *