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 globale. C’est en confondant ces deux notions que l’expression « terminé » en vient discrètement à signifier « ça fonctionne sur mon ordinateur ».

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é » comble 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, la notion de « terminé » relève de l’opinion de chacun, 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é relu 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 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. 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é.

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 développé ce qu’il fallait ? ». La définition de « terminé » est globale et répond à la question « notre travail est-il 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 opposition à la définition de « terminé »

Ce sont des repères, pas des jumeaux symétriques. La définition de « prêt » permet à une story d’être intégrée dans le sprint : suffisamment petite, suffisamment claire, estimée. La définition de « terminé » permet au travail achevé d’être exclu du sprint. « Prêt » concerne la story ; « terminé » concerne le travail. Les équipes qui n’en ont qu’une seule ont généralement la notion de « prêt » (car les stories non prêtes se font remarquer) et laissent discrètement la notion de « 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’acceptationDéfinition de « terminé »
Champ d’applicationDans le monde entier, chaque histoireActualités locales : cet articleDans le monde entier, chaque histoire
GatesEntrée dans le sprintLe dénouement de l’histoire elle-mêmeSortie du sprint
Réponses« On peut commencer ? »« Avons-nous créé ce qu’il fallait ? »« Est-ce que cela peut être expédié ? »
PropriétaireL’équipe, avec le responsable produitResponsable produit, au sein de l’équipeL’é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 la réflexion 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 la question lors d’une rétrospective lorsque le même écart persiste ; c’est le signe qu’une ligne manque à l’appel.

Qu’est-ce qui ne va pas ?

La définition de « terminé » se retrouve sur une affiche. Elle est épinglée sur le wiki de l’équipe, répété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 si 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’itérative. 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 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 : en général, elle doit avoir été testée, faire l’objet d’une révision du code, avoir été fusionnée, documentée et déployée sur l’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 existe pour 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 sont locaux, 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 » porte sur la bonne formulation de la story ; le critère « terminé » porte sur le fait que le travail soit prêt à être mis en production.

Qui définit ce qu’est un « travail terminé » ?

C’est l’équipe de développement qui en est responsable, généralement avec l’aide 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 paient le prix lorsque cette notion est définie de manière trop vague.

Lectures complémentaires