Définition du terme « terminé » (DoD) : liste de contrôle et exemples

La définition de « terminé » (DoD) est la courte liste de contrôle sur laquelle une équipe s’accorde pour déterminer les conditions que chaque story doit remplir avant d’être considérée comme achevée : révisée, testée, fusionnée, déployée, acceptée. Il s’agit d’une norme unique pour l’ensemble de l’équipe. Les critères d’acceptation s’appliquent à chaque story ; la définition de « terminé » est globale. C’est en confondant ces deux notions que l’expression « terminé » en vient discrètement à signifier « ça fonctionne sur ma machine ».

Chaque équipe a déjà constaté l’écart entre « le développeur dit que c’est terminé » et « c’est réellement prêt à être déployé ». La définition de « terminé » permet de combler cet écart. Vous vous mettez d’accord une fois pour toutes et vous l’appliquez à chaque sprint, quel que soit le contenu de chaque story. Sans cela, le terme « terminé » relève d’une opinion personnelle, et la différence apparaît lors de la démonstration, ou pire encore, en production.

Que signifie la « définition du « terminé » » dans Scrum ?

Le Guide Scrum la définit comme « une description formelle de l’état de l’incrément lorsqu’il répond aux critères de qualité requis pour le produit ». En termes simples, la définition de « terminé » correspond à l’engagement associé à l’incrément, l’un des trois artefacts Scrum. Le travail qui y répond fait partie intégrante de l’incrément. Le travail qui ne répond pas à cette définition ne peut être ni livré ni présenté lors de la revue du sprint ; il est renvoyé dans le backlog produit.

Si votre organisation a déjà défini une « définition du « terminé » », chaque équipe l’utilise comme critère minimum et peut y ajouter des éléments. Si ce n’est pas le cas, l’équipe rédige la sienne. Ce principe ne se limite pas à Scrum : les équipes Kanban établissent souvent la même liste, qui sert de règle pour faire passer le travail dans leur colonne finale.

Exemples illustrant la définition de « terminé »

Exemple de liste de contrôle « « Définition de « terminé » » » : une équipe de développement logiciel

Un point de départ concret pour une équipe chargée de la mise en production d’une application web :

• Les critères d’acceptation ont été respectés et vérifiés.
• Le code a été révisé et intégré à la branche principale.
• Les tests automatisés ont été écrits et se sont avérés concluants ; aucun nouveau test instable n’a été détecté.
• Aucune régression connue ni aucun bogue critique en cours n’est signalé concernant cet élément.
• La documentation et le journal des modifications ont été mis à jour lorsque la modification concerne les utilisateurs.
• Déployé sur l’environnement de préproduction et soumis à des tests de validation.
• Le responsable produit l’a accepté.

Inspirez-vous de ceci, puis adaptez-le à ce que votre équipe mettra réellement en pratique. Une définition de « terminé » comportant un critère que personne ne vérifie est pire qu’une définition succincte. Cela incite l’équipe à considérer l’ensemble de la liste comme purement symbolique. Veillez à ce qu’elle tienne sur un seul écran et à ce que chaque élément puisse être vérifié.

Exemple illustrant la notion de « terminé » : une équipe qui ne publie pas de code

Ce principe s’applique également à une équipe de marketing, de contenu ou de conception. La définition de « terminé » d’une équipe de contenu pourrait se présenter ainsi :

• Les critères d’acceptation du cahier des charges sont respectés.
• Rédigé par une personne autre que l’auteur.
• Les faits, les chiffres et les liens ont été vérifiés.
• Les principes de base de l’accessibilité sont respectés : texte alternatif, ordre des titres, contraste suffisant.
• Approuvé par la personne qui en a fait la demande.
• Publié ou transmis, et consigné à un endroit accessible à toute l’équipe.

Niveaux « story », « sprint » et « release »

La méthode Scrum exige une définition unique de « terminé » pour l’incrément. Dans la pratique, de nombreuses équipes regroupent les vérifications en fonction du moment où elles s’effectuent naturellement :

Niveau	S’applique à	Articles courants
Histoire	Chaque élément du carnet de commandes	Code validé, tests réussis, critères d’acceptation respectés, validation par le Product Owner
Sprint	L’Increment dans son ensemble	Intégré sur la branche principale, suite de tests de régression réussie, déployé sur l’environnement de préproduction
Communiqué	Ce qui touche les clients	Les notes de mise à jour ont été rédigées, les contrôles de sécurité et de performances ont été effectués, le service d’assistance a été informé

Conservez le niveau de l’itérative comme liste principale. Si une vérification ne peut avoir lieu qu’au moment de la mise en production, indiquez-le également sur la liste, afin que personne ne marque une itérative comme terminée en partant du principe que quelqu’un d’autre repérera cette lacune plus tard.

Comment rédiger une définition de « terminé »

1. Commencez par ce qui vous échappe sans cesse. Examinez les derniers sprints : les bugs découverts après la phase « terminé », les stories qui ont été renvoyées, les tâches reportées. Chacune d’entre elles met en évidence une étape manquante.
2. Rédigez-la avec l’ensemble de l’équipe. Les personnes qui réalisent le travail s’accordent sur ce point au cours d’une seule réunion, animée par le Scrum Master et en présence du Product Owner. Une liste imposée de l’extérieur ne sera pas défendue par l’équipe lorsqu’elle sera sous la pression des délais.
3. Veillez à ce que chaque ligne puisse être vérifiée. « Testé » est une impression ; « tests automatisés écrits et réussis en CI » est une vérification. Si deux personnes ne parviennent pas à s’accorder sur le respect d’une ligne, réécrivez-la.
4. Limitez-vous à ce que vous allez réellement mettre en œuvre dès maintenant. Nous commencerions par cinq à huit lignes. Ajoutez les objectifs ambitieux lorsque l’équipe sera réellement en mesure de les atteindre.
5. Placez-la là où le travail s’effectue. Une liste de contrôle intégrée au modèle de ticket ou figurant dans la colonne « Terminé » du tableau sera utilisée. Une page sur le wiki sera oubliée.
6. Vérifiez-le lors de la rétrospective. Lorsqu’une même lacune réapparaît deux fois, ajoutez une ligne. Lorsqu’une ligne est cochée sans que personne ne l’ait vérifiée, demandez-vous si elle a toujours sa place.

Définition de « terminé » par rapport aux critères d’acceptation

C’est la distinction sur laquelle les équipes butent le plus souvent. Les critères d’acceptation d’une story de connexion sont spécifiques à la connexion : des identifiants corrects vous mènent au tableau de bord, trois tentatives infructueuses verrouillent le compte. La définition de « terminé » (révisé, testé, déployé) est identique pour la story de connexion, la story de recherche et la story de facturation. Les critères sont locaux et répondent à la question « avons-nous construit ce qu’il fallait ? ». La définition de « terminé » est globale et répond à la question « notre travail est-il à un moment donné prêt à être livré ? ». Une histoire n’est pas terminée tant qu’elle n’a pas franchi ces deux étapes.

Définition de « prêt » par rapport à celle de « terminé »

Ce sont des repères, pas des jumeaux symétriques. La définition de « prêt » permet à une story d’entrer dans le sprint : suffisamment petite, suffisamment claire, estimée. La définition de « terminé » permet au travail achevé d’en sortir. « Prêt » concerne la story ; « terminé » concerne le travail. Les équipes qui n’en ont qu’une seule ont généralement le statut « prêt » (car les stories non prêtes se font remarquer) et laissent discrètement le statut « terminé » passer à la trappe, ce qui explique pourquoi les stories reportées et celles « achevées à 90 % » s’accumulent.

Ces trois listes de contrôle ne se confondent plus dès lors que vous comprenez ce que chacune d’entre elles contrôle :

	Définition du terme « prêt »	Critères d’acceptation	Définition de « terminé »
Champ d’application	Dans le monde entier, chaque histoire	Actualité locale : cet article	Dans le monde entier, chaque histoire
Gates	Entrée dans le sprint	Le dénouement de l’histoire elle-même	Fin du sprint
Réponses	« Pouvons-nous commencer ? »	« Avons-nous créé ce qu’il fallait ? »	« Est-ce que cela peut être expédié ? »
Propriétaire :	L’équipe, avec le responsable produit	Responsable produit, au sein de l’équipe	L’équipe

À qui revient-il de définir ce qu’est un travail « terminé » ?

C’est l’équipe qui le rédige ; c’est l’équipe qui le fait respecter. Le Scrum Master anime le processus, et le Product Owner donne son avis sur le seuil d’acceptation, mais ce sont les ingénieurs qui décident de ce qu’implique techniquement le terme « terminé », car une définition floue de ce terme constitue une dette qu’ils doivent rembourser, et non la direction. Réexaminez-le lors d’une rétrospective lorsque le même écart revient sans cesse ; c’est le signe qu’il manque une ligne.

En quoi la définition de « terminé » modifie vos estimations

Les story points évaluent le travail jusqu’à son achèvement complet, et non jusqu’à la « fin du codage ». La définition de « terminé » est donc intégrée à chaque estimation. Ajoutez une ligne du type « tests de performance effectués » et chaque story prendra un peu plus d’ampleur. Lorsque la liste évolue, revérifiez vos stories de référence lors de la prochaine session de planification, sinon la vélocité baissera pour une raison que personne ne pourra expliquer.

Qu’est-ce qui ne va pas ?

La définition de « terminé » devient une affiche. Elle est épinglée sur le wiki de l’équipe, récitée lors de l’intégration des nouveaux membres, puis ignorée sous la pression des délais : « Nous rédigerons les tests lors du prochain sprint. » Deux sprints plus tard, la dette de tests est devenue structurelle et la définition n’est plus qu’une fiction. Lorsque la notion de « terminé » est floue, la vélocité gonfle : l’équipe accumule des points pour un travail qui n’est pas réellement livrable, et les prévisions perdent discrètement tout leur sens.

La solution ne réside pas dans une liste plus longue, mais dans une liste plus courte sur laquelle l’équipe saura rester ferme. Une définition de « terminé » n’a de sens que dans la mesure où vous êtes prêt à ne pas marquer une tâche comme terminée parce qu’elle ne répond pas à l’un de ses critères.

Les critères d’acceptation constituent une étape de validation pour l’épisode. La définition de « terminé » constitue une étape de validation pour l’équipe. Veillez à ce qu’elle soit suffisamment concise pour que vous puissiez réellement la faire respecter. Une étape de validation qui n’est pas appliquée n’est qu’une simple formalité administrative.

Foire aux questions

Quelle est la définition de « terminé » dans la méthode agile ?

La définition de « terminé » (DoD) est une liste de contrôle unique à laquelle chaque story doit satisfaire avant d’être considérée comme achevée : en général, elle doit avoir été testée, faire l’objet d’une revue de code, avoir été fusionnée, documentée et déployée en environnement de préproduction. Il s’agit d’une norme commune à toute l’équipe, et non d’une liste propre à chaque story ; elle a pour but de garantir que le terme « terminé » ait toujours la même signification, quelle que soit la personne qui l’utilise.

Quelle est la différence entre la définition de « terminé » et les critères d’acceptation ?

La définition de « terminé » est globale ; il s’agit d’un critère unique pour chaque story. Les critères d’acceptation, quant à eux, sont locaux, c’est-à-dire spécifiques à une story donnée. Les critères d’acceptation précisent ce que cette fonctionnalité doit faire ; la définition de « terminé » définit ce que signifie « prêt à être livré » pour tout travail produit par l’équipe. Une story doit satisfaire à ces deux critères.

Qu’est-ce qu’une liste de contrôle « définition de « terminé » » ?

Une liste concise et explicite des conditions applicables à chaque story : code revu et intégré, tests rédigés et réussis, aucune régression connue, documentation mise à jour, déploiement vers un environnement de test et validation par le Product Owner. Les éléments précis varient d’une équipe à l’autre, mais la liste doit tenir sur un seul écran et chaque ligne doit pouvoir être vérifiée.

Quelle est la différence entre la définition de « prêt » et celle de « terminé » ?

Les critères de « prêt » marquent l’entrée dans le sprint ; il s’agit du seuil qu’une story doit franchir avant que l’équipe ne s’y engage. Les critères de « terminé » marquent la sortie du sprint ; il s’agit du seuil que le travail achevé doit franchir avant sa mise en production. Le critère « prêt » concerne la bonne formulation de la story ; le critère « terminé » concerne le fait que le travail soit prêt à être mis en production.

Comment rédiger une définition de « terminé » ?

Commencez par ce qui vous échappe sans cesse : les bugs, les retouches et les éléments reportés des derniers sprints. Mettez-vous d’accord sur cette liste avec toute l’équipe, rédigez chaque ligne de manière à ce qu’elle appelle une réponse par « oui » ou par « non », réduisez-la à ce que vous allez réellement appliquer, et placez-la là où le travail s’effectue, par exemple dans le modèle de ticket. Revenez-y ensuite lors de la rétrospective chaque fois qu’un élément passe entre les mailles du filet.

Qui établit la définition de « terminé » ?

C’est l’équipe de développement qui en est responsable, généralement sous la houlette du Scrum Master. Le Product Owner donne son avis sur les critères d’acceptation, mais ce sont les personnes qui effectuent le travail qui décident de ce que signifie techniquement « terminé », car ce sont elles qui en font les frais lorsque ces critères sont définis de manière trop vague.

Lectures complémentaires

• Estimation agile : le guide complet : retrouvez ici toutes les informations nécessaires.
• Critères d’acceptation : le test par story avec lequel on confond souvent la définition de « terminé ».
• Définition de « prêt » : la ligne d’arrivée située à l’autre extrémité du sprint.
• Erreurs dans le Planning Poker : comment un « terminé » trop vague gonfle la vélocité.