Affinement du backlog (grooming) : cadence, responsabilité et signification du terme « prêt »

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 qui se déroule dans le calme 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’affinement du backlog parmi les événements — il le décrit comme une activité continue qui ne devrait pas mobiliser plus de 10 % environ 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 une place fixe au calendrier à l’affinement 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 de sprint, où il s’avère plus onéreux et moins opportun.

En quoi consiste réellement le raffinage ?

Le raffinage 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 se succèdent sans interruption :

• Précisez. Transformez « améliorer l’intégration » en un objectif dont l’intention est claire et assorti de critères d’acceptation que l’équipe pourra vérifier.
• Décomposition. Décomposez les tâches trop volumineuses pour être menées à bien en un seul sprint en petites parties distinctes, chacune présentant une valeur en soi. Il s’agit là d’un art à part entière — voir la décomposition des user stories.
• Taille. Convenez d’une estimation en story points, généralement à l’aide du planning poker, afin que l’effort relatif soit bien compris avant tout engagement.
• 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 de manière ponctuelle à 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 exact 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 le juste milieu. Si la planification est insuffisante, elle se transforme en un travail de précision mené sous la pression du temps : l’équipe clarifie et décompose les tâches à la hâte, puis s’engage à réaliser un travail qu’elle comprend à peine. Si elle est trop importante, le peaufinage se transforme en une deuxième réunion de planification, où l’on débat des détails d’éléments qui pourraient ne jamais être intégrés à un sprint. Respectez la recommandation du Guide Scrum, qui préconise d’y consacrer environ 10 % de la capacité, et cette étape restera utile.

Qui en est responsable ?

Le Product Owner est responsable du backlog : la priorité, l’objectif et la raison d’être de chaque élément relèvent de sa responsabilité. 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 dégénère 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 simplifiée de « prêt » correspond à la liste de contrôle qu’un élément doit satisfaire 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 réaliser. Si la frontière entre ces deux processus vous semble floue au sein de votre équipe, l’article Planification de sprint vs raffinement du backlog la définit clairement. Pour savoir où se situe le raffinement par rapport aux événements formels, consultez É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 charge de travail 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 arrive en 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 lui consacrent une session récurrente et la traitent comme une cérémonie, car c’est en la négligeant que la planification du sprint tourne au 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, en s’appuyant sur une brève réunion récurrente — 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 ainsi que les objectifs, mais le raffinement est une activité d’équipe : 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 à la réunion de planification.