Affinement du backlog (grooming) : cadence, responsabilité et signification du terme « prêt »
L'affinage du backlog, également appelé « grooming », consiste en un travail continu visant à préparer les éléments avant le sprint au cours duquel ils seront développés : clarification, estimation, découpage et classement.
L’affinage du backlog, encore largement appelé « grooming », consiste en un travail continu visant à préparer les éléments du backlog produit avant le sprint au cours duquel ils seront développés : clarifier la signification de chaque élément, diviser ceux qui sont trop volumineux, ajouter des critères d’acceptation, en estimer la taille et les classer par ordre de priorité. Il ne s’agit pas tant d’une réunion ponctuelle que d’une habitude. Et c’est ce qui fait toute la différence entre une planification de sprint sereine et une planification de sprint qui se transforme en une dispute de deux heures.
S’agit-il d’une cérémonie ou non ?
Techniquement, non. Le Guide Scrum ne mentionne pas l’affinage du backlog parmi les événements. Il le décrit comme une activité continue qui ne devrait pas mobiliser plus d’environ 10 % de la capacité des développeurs. Les puristes ont donc raison : ce n’est pas une cérémonie.
Et pourtant, le guide d’Asana sur les cérémonies agiles s’intitule « 4 événements + affinement du backlog », et la plupart des équipes de travail réservent à l’affinement un créneau fixe dans leur agenda et le mènent comme n’importe quelle autre cérémonie. Les deux camps mettent en avant la même vérité sous des angles différents : l’affinement n’est pas un événement formel, mais le traiter comme tel est généralement la bonne décision. Si vous le négligez, le coût ne disparaît pas pour autant. Il est simplement reporté à la planification du sprint, où il s’avère plus coûteux et moins opportun.
En quoi consiste réellement le raffinage ?
Le raffinement consiste à transformer les éléments bruts du backlog (souvent un titre et un vague espoir) en éléments exploitables. Concrètement, cela se traduit par quatre étapes qui s’enchaînent sans interruption :
- Précisez. Transformez « améliorer l’intégration » en un objectif dont l’intention est claire et dont les critères d’acceptation permettent à l’équipe de vérifier si l’objectif a été atteint.
- Décomposition. Décomposez les tâches trop volumineuses pour être menées à bien en un seul sprint en petites parties distinctes ayant chacune une valeur intrinsèque. Il s’agit là d’un art à part entière : voir la section consacrée à la décomposition des user stories.
- Taille. Convenez d’une estimation commune en « story points », généralement à l’aide du « planning poker », afin de bien cerner l’effort relatif requis avant de vous engager.
- Ordre. Veillez à ce que le carnet de commandes soit trié de manière à ce que les tâches les plus importantes et les plus avancées figurent en tête de liste, afin que les responsables de la planification puissent les sélectionner en priorité.
Le résultat n’est pas un document. Il s’agit d’un tampon glissant contenant des éléments prêts à être sélectionnés, généralement un ou deux sprints en avance par rapport à la situation actuelle de l’équipe.
Fréquence : à quelle fréquence, pendant combien de temps
Il n’y a pas de règle, mais il existe une valeur par défaut raisonnable : une courte séance régulière servant de point d’ancrage, complétée par de petites interventions régulières entre les deux.
Pour un sprint de deux semaines, la plupart des équipes organisent une seule session de raffinement à mi-parcours, d’une durée fixée à environ une heure, et la complètent au fur et à mesure que des questions se posent. Une fréquence hebdomadaire fonctionne tout aussi bien. Ce qui importe, ce n’est pas tant le créneau horaire précis que la « marge » : l’objectif est de toujours disposer d’une file d’attente contenant environ l’équivalent d’un sprint de tâches prêtes à être traitées, afin que la planification ne se retrouve jamais face à un backlog vide ne contenant aucune tâche pouvant faire l’objet d’un engagement.
Deux écueils encadrent la quantité idéale. Si elle est insuffisante, la planification se transforme en affinage sous la pression du temps : l’équipe clarifie et découpe les tâches à la hâte, puis s’engage à réaliser un travail qu’elle comprend à peine. Si elle est trop importante, le raffinement se transforme en une deuxième réunion de planification, où l’on débat longuement de détails concernant des éléments qui n’atteindront peut-être jamais un sprint. C’est là que se manifeste le raffinement excessif, une surcharge de formalités qui ne rapporte rien en contrepartie. Restez dans les limites de la recommandation du Guide Scrum, soit environ 10 % de la capacité, et cela restera utile.
Qui s’en charge ?
Le Product Owner est responsable du backlog : la priorité, l’objectif et la raison d’être de chaque élément lui incombent. Mais le raffinement est un travail d’équipe. Ce sont les développeurs qui posent les questions délicates, mettent en évidence la complexité que personne n’avait prise en compte et procèdent à l’estimation réelle. Un Product Owner qui affine seul le backlog produit des éléments qui ne sont parfaitement clairs que pour une seule personne et qui réservent de nombreuses surprises à tous les autres dès le début de la planification.
Le Scrum Master veille à ce que la session respecte la durée prévue et empêche qu’elle ne se transforme en « conception collective ». Par ailleurs, moins il y a de spectateurs, mieux c’est.
Que signifie « prêt » ? : la définition du terme « prêt »
L’objectif du raffinement est de rendre les éléments prêts, et le terme « prêt » mérite une définition, tout comme « terminé ». Une définition simple de la notion de « prêt » correspond à la liste de contrôle qu’un élément doit respecter avant que l’équipe ne s’engage à le prendre en charge lors de la planification : il est bien compris, il est suffisamment petit pour être terminé en un sprint, il dispose de critères d’acceptation, ses dépendances sont connues et il a fait l’objet d’une estimation.
Le raffinement et la planification constituent un relais, et non une rivalité. Le raffinement prépare les éléments, tandis que la planification s’engage à les prendre en compte. Si la frontière entre ces deux processus vous semble floue au sein de votre équipe, la comparaison entre la planification de sprint et le raffinement du backlog permet de la définir clairement. Pour savoir où se situe le raffinement par rapport aux événements formels, consultez la rubrique « Événements Scrum vs cérémonies ».
Foire aux questions
Qu’est-ce que l’affinement du backlog ?
L’activité continue consistant à préparer les éléments du backlog produit en vue de leur traitement : clarifier la signification de chaque élément, diviser les plus volumineux, ajouter des critères d’acceptation, en estimer la taille et les réorganiser par ordre de priorité. Ce processus se déroule en continu tout au long du sprint, de sorte que lorsqu’un élément parvient à la phase de planification, l’équipe puisse s’engager à le réaliser sans difficulté.
Le raffinement du backlog est-il une cérémonie Scrum ?
Non. Le Guide Scrum ne la mentionne pas comme un événement. Il s’agit d’une activité continue, et non d’une réunion fixe, et le Guide Scrum précise qu’elle ne devrait pas occuper plus d’environ 10 % de la capacité des développeurs. Cependant, la plupart des équipes y consacrent une session récurrente et la traitent comme une cérémonie, car c’est le fait de la négliger qui plonge la planification du sprint dans le chaos.
Quelle est la différence entre le « backlog grooming » et le « backlog refinement » ?
Aucune. Il s’agit de la même activité. « Grooming » est le terme d’origine ; la communauté Scrum a opté pour « refinement » car « grooming » avait pris des connotations fâcheuses. De nombreuses équipes continuent toutefois d’utiliser le terme « grooming ». Le travail reste identique dans les deux cas.
À quelle fréquence devez-vous affiner le backlog ?
De manière continue, avec une brève session récurrente servant de point d’ancrage : généralement une fois par semaine, ou une fois au milieu d’un sprint pour un rythme de deux semaines, d’une durée fixée à environ une heure. L’objectif est de disposer d’une réserve glissante d’éléments prêts à être traités, généralement avec une ou deux semaines d’avance sur le sprint, afin que la planification dispose toujours de ressources de qualité sur lesquelles s’appuyer.
Qui est chargé de l’affinement du backlog ?
Le Product Owner est responsable du backlog et définit les priorités et les objectifs, mais le raffinement est une activité collective. Ce sont les développeurs qui posent les questions, mettent en évidence les complexités cachées et évaluent l’ampleur des tâches. Un Product Owner qui procède seul au raffinement produit des éléments qui n’ont de sens que pour lui et qui surprennent tous les autres participants lors de la planification.