Définition de « terminé »

La définition de « terminé » consiste en une liste de contrôle unique pour l’ensemble de l’équipe — la norme que chaque story doit respecter avant d’être considérée comme achevée. Les critères d’acceptation s’appliquent à chaque story ; la définition de « terminé » est quant à elle globale. C’est en confondant ces deux notions que l’expression « terminé » en vient discrètement à signifier « ça fonctionne sur mon ordinateur ».

Toutes les équipes ont déjà constaté l’écart entre « le développeur dit que c’est terminé » et « c’est réellement prêt à être mis en production ». La définition de « terminé » permet de combler cet écart. Vous vous mettez d’accord sur cette définition 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.

Une liste de contrôle relative à la définition de « terminé » (exemple)

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 déroulés avec succès ; aucun nouveau test instable n’a été détecté.
• Aucune régression connue ni aucun bug critique en cours n’est signalé concernant cette fonctionnalité.
• 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 : elle 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é.

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

C’est la distinction qui pose le plus souvent problème aux équipes. 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 développé 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 story 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 s’en tiennent généralement à « prêt » (car les stories non prêtes se font remarquer) et laissent discrètement « terminé » passer à la trappe — ce qui explique pourquoi les reports et les stories « 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és locales — 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	« On peut commencer ? »	« Avons-nous créé ce qu’il fallait ? »	« Est-ce que ça peut être expédié ? »
Propriétaire :	L’équipe, avec le Product Owner	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 un « terminé » mal défini constitue une dette qu’ils devront rembourser, et non la direction. Réexaminez la question lors d’une rétrospective lorsque la même lacune revient sans cesse ; c’est le signe qu’il manque une ligne.

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 test 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 décisive pour l’itérative. La définition de « terminé » constitue une étape décisive pour l’équipe. Veillez à ce qu’elle soit suffisamment concise pour que vous puissiez réellement la faire respecter — une étape qui n’est pas respecté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é » consiste en une liste de contrôle unique à laquelle chaque story doit satisfaire avant d’être considérée comme achevée — généralement : testée, soumise à une revue de code, fusionnée, documentée et déployée en environnement de préproduction. Il s’agit d’une norme commune à l’ensemble de 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’une même étape pour chaque story. Les critères d’acceptation sont locaux : ils sont spécifiques à une story donnée. Les critères d’acceptation précisent ce que cette fonctionnalité doit faire ; la définition de « terminé » précise 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 précise 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 dans 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 — c’est le seuil qu’une story doit franchir avant que l’équipe ne s’y engage. Les critères de « terminé » marquent la sortie du sprint — c’est le seuil que le travail achevé doit franchir avant d’être livré. 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 livré.

Qui définit ce qu’est un « travail 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 cette notion est définie de manière trop vague.

Lectures complémentaires

• L’estimation agile : le guide complet — la plateforme de référence pour tout ce qui concerne ce sujet.
• Critères d’acceptation — le test associé à chaque story avec lequel on confond souvent la définition de « terminé ».
• Définition de « ready » — la ligne d’arrivée située à l’autre extrémité du sprint.
• Erreurs liées au Planning Poker — comment un « terminé » trop vague gonfle la vélocité.