Déroulé d'une réunion d'affinage du backlog : une structure de 60 minutes et la règle de ce qui reste dehors

La plupart des réunions d'affinage du backlog échouent par dérive du périmètre. Ce qui commence comme un point de 45 minutes sur le détail des tickets se transforme en une dispute d'une heure sur l'architecture, des estimations de user stories que personne n'a encore écrites et un nouveau tour du débat sur la roadmap que tout le monde croyait réglé au trimestre précédent. À la fin, le Product Owner a une page de notes griffonnées et rien n'est prêt pour le sprint suivant.

La solution est simple : une structure fixe de 60 minutes, des critères d'entrée que chaque élément doit satisfaire avant d'avoir droit à du temps de parole, et une règle, énoncée à voix haute au début, sur ce dont la réunion ne discutera pas. Cet article présente ce déroulé. Pour la définition générale de l'affinage et sa place dans Scrum, lisez le guide de l'affinage du backlog et la page de la méthode Backlog Refinement. Je ne les répéterai pas ici.

Pourquoi l'affinage a besoin d'une timebox fixe

L'affinage est l'une des rares activités Scrum sans format prescrit. Le Scrum Guide le décrit comme une activité continue plutôt que comme un événement, si bien que chaque équipe invente sa propre version. En pratique, un format inventé et sans structure revient par défaut à celui qui parle le plus fort. C'est généralement l'ingénieur le plus senior ou le Product Owner, et les développeurs plus discrets, ceux qui vont construire la chose, cessent de contribuer au bout d'une quinzaine de minutes.

Il existait autrefois un repère : l'édition 2017 du Scrum Guide indiquait que l'affinage « ne consomme généralement pas plus de 10 % de la capacité de l'équipe de développement ». L'édition actuelle a supprimé ce chiffre, mais les formateurs Scrum le citent encore. Considérez ces 10 % comme un plafond. La plupart des équipes obtiennent ce dont elles ont besoin avec une séance de 60 minutes par semaine, plus la préparation du PO et quelques clarifications asynchrones dans les commentaires des tickets. On reste bien en dessous du plafond, et cela laisse aux développeurs du temps pour construire.

Un affinage sans limite échoue de manière prévisible. Les trois mêmes éléments absorbent presque toute la discussion, semaine après semaine, tandis qu'une douzaine d'autres user stories ne sont jamais examinées avant la sprint planning. La planification se transforme alors en affinage, et tout ce qui suit prend du retard.

Backlog grooming ou affinage

« Grooming » était le terme informel utilisé aux débuts de la pratique Scrum pour le rangement du backlog : réordonner, supprimer les éléments périmés, faire un peu de ménage. « Refinement » (affinage) est devenu le terme officiel lorsque le secteur a reconnu ce travail comme une activité à part entière, et des organisations comme Scrum.org ont abandonné « grooming » en partie à cause de ses connotations négatives sans rapport avec le sujet (le Scrum Glossary utilise désormais refinement partout). La plupart des équipes emploient aujourd'hui les deux mots indifféremment, et je ne reprends personne qui dit grooming. La différence fonctionnelle mérite toutefois d'être conservée. Le grooming évoque un entretien passif qu'une seule personne peut faire seule. L'affinage est une préparation active et collaborative d'éléments précis par les personnes qui vont les construire, et c'est pourquoi ce déroulé le traite comme une séance de travail avec des critères d'entrée.

En quoi l'affinage diffère de la sprint planning

L'affinage est préparatoire et continu. Il a lieu en milieu de sprint, Scrum ne lui impose aucune cadence, et il produit des éléments de backlog plus clairs, plus petits et estimés approximativement. La sprint planning est un événement Scrum formel et timeboxé, tenu une fois au début de chaque sprint, et elle produit un Sprint Goal et un Sprint Backlog.

Les deux posent aussi des questions différentes. L'affinage demande : cet élément est-il assez bien compris pour être estimé et, à terme, planifié ? La sprint planning demande : lesquels de ces éléments déjà compris intégrons-nous, et comment allons-nous les livrer ?

Confondre les deux est la raison la plus fréquente pour laquelle je vois une sprint planning exploser sa timebox. Une équipe arrive à une séance de planification de deux heures avec des user stories non affinées et passe les 30 premières minutes à les découper et à se disputer sur les critères d'acceptation. Les équipes qui sautent l'affinage découvrent leurs inconnues en direct, pendant la planification, là où elles coûtent le plus cher.

Ce que le Product Owner prépare à l'avance

Une séance d'affinage ne vaut que par la préparation du PO. Quand le PO arrive sans préparation et fait défiler Jira à la recherche de « quelque chose dont on pourrait parler », les dix premières minutes sont perdues et le reste de l'heure n'a pas de forme. Je demande aux PO ce qui suit au moins 24 heures avant la séance :

• Une liste ordonnée d'éléments candidats, généralement de quoi remplir les un à deux prochains sprints, le haut de la liste étant ce que l'équipe verra en premier.
• Le contexte connu joint à chaque élément : maquettes, liens vers des tickets liés, dépendances envers d'autres équipes, citations de clients.
• Chaque élément étiqueté soit « prêt à affiner », soit « nécessite une découverte hors séance ».
• Les questions ouvertes qui nécessitent l'avis de parties prenantes signalées, avec une note indiquant qui est chargé d'obtenir la réponse.

L'étiquetage est ce qui compte le plus. Les éléments qui n'ont même pas un énoncé de problème de base doivent être écartés, car ils nécessitent une conversation de découverte, et l'affinage n'est pas le bon lieu pour la découverte. Quand un PO arrive avec des éléments déjà répartis entre ces deux catégories, je saute entièrement la seconde. Personne ne conteste, parce que le PO a tranché avant la réunion.

Les critères d'entrée de chaque élément

Les critères d'entrée sont une courte checklist qu'un élément doit satisfaire avant de mériter du temps de discussion. Beaucoup d'équipes appellent cela une Definition of Ready allégée. Voici l'ensemble avec lequel je fais démarrer les équipes :

1. L'élément a une user story ou un énoncé de problème clair en une phrase.
2. Les critères d'acceptation sont rédigés, même s'ils sont incomplets.
3. Il n'y a pas de dépendance bloquante envers une question d'architecture non tranchée.
4. Il est assez petit pour tenir dans un sprint, ou il est explicitement signalé comme à découper.

Une checklist permet à l'animateur de dire « cela ne remplit pas les critères, suivant » sans que cela sonne comme un jugement personnel. C'est dans les arbitrages faits sur le moment que l'affinage dérive vers le débat.

Les développeurs doivent rédiger la checklist avec vous. Si le PO ou le Scrum Master l'impose, l'équipe la traite comme de la bureaucratie et la conteste en pleine séance. Ce sont les développeurs qui doivent répondre à la question « est-ce que je comprends cela assez bien pour l'estimer », c'est donc à eux de rédiger les critères qui la définissent. Consacrez-y un créneau de 20 minutes lors d'une rétrospective et revoyez-la tous les quelques mois.

Le déroulé de 60 minutes de la réunion d'affinage du backlog

Voici le déroulé de réunion d'affinage du backlog que j'utilise, en cinq blocs, chacun avec son propre minuteur.

• Minutes 0-5 : énoncez l'objectif (« rendre prêts les prochains éléments »), rappelez la règle de ce qui est hors périmètre et confirmez avec le PO la file d'éléments pré-triée. Si le PO veut réordonner, cela se fait ici, en moins d'une minute.
• Minutes 5-15 : passez en revue les deux ou trois premiers éléments au regard des critères d'entrée. Les éléments qui échouent retournent au PO avec une note sur ce qui manque. Ceux qui passent vont au bloc suivant.
• Minutes 15-45 : discussion et estimation, un élément à la fois, avec une timebox stricte de 8 à 10 minutes par élément. Le PO explique le problème, les développeurs posent des questions, l'équipe estime.
• Minutes 45-55 : découpez tout élément qui s'est révélé trop gros et resserrez la formulation des critères d'acceptation des éléments désormais prêts.
• Minutes 55-60 : récapitulez les décisions, passez en revue le parking, attribuez des responsables aux sujets parqués et confirmez la date de la prochaine séance.

Cela vous donne trois ou quatre éléments par séance. Les équipes habituées à « couvrir » quinze tickets en une heure trouvent cela lent au début, mais trois éléments réellement prêts valent plus que quinze approuvés d'un hochement de tête et qui reviendront sur la table en planification.

Minuter chaque bloc, et le minuteur par élément

Une timebox sur l'ensemble de la réunion ne suffit pas. Les groupes étirent la discussion pour remplir tout le temps disponible, c'est pourquoi les timebox doivent porter sur chaque activité. Affichez un minuteur visible pour chaque bloc et pour chaque élément. Quand la sonnerie des 8 minutes retentit sur une user story encore contestée, je dis « mettons cela au parking et traitons-le hors séance », et je passe à la suite. Cette seule habitude sauve plus de séances d'affinage que tout ce que je connais.

Pour l'estimation elle-même, utilisez ce en quoi votre équipe a déjà confiance. Le Planning Poker fonctionne ; l'estimation agile en tailles de T-shirt aussi, si votre équipe préfère des catégories relatives aux chiffres. Choisissez-en une et ne rouvrez pas le choix de l'échelle chaque semaine.

Je construis ce déroulé une fois pour toutes comme modèle réutilisable dans Workshop Weaver, avec les cinq blocs et leurs durées fixés, pour que l'animateur n'ait pas à reconstruire la structure de mémoire chaque semaine. Un déroulé publié fixe aussi les attentes ; comme je l'ai soutenu dans Votre déroulé est une promesse, les blocs de temps sont un engagement envers les personnes présentes dans la salle.

Le parking

Tenez un parking visible dans le document partagé ou sur le tableau blanc. Les digressions issues du bloc de discussion y sont notées avec le nom de la personne qui les a soulevées. Dans les cinq dernières minutes, chaque élément parqué reçoit un responsable et une prochaine étape. Sans responsables, l'équipe apprend vite que « le mettre au parking » signifie « l'ignorer ».

Ce qui reste en dehors de l'affinage

La règle que je lis à voix haute au début de chaque séance : l'affinage s'arrête à « comprenons-nous le problème, et quelle est sa taille approximative ? » Tout ce qui dépasse cette ligne va ailleurs. Trois catégories la franchissent le plus souvent.

La conception des solutions

La manière dont l'ingénierie sera construite relève d'un spike technique ou d'une conversation de conception séparée. Élaborer la solution complète pendant l'affinage tourne au débat auquel seules deux ou trois personnes dans la salle peuvent contribuer, pendant que tous les autres consultent leurs e-mails. Quand un développeur dit « eh bien, on pourrait construire cela de trois façons différentes », je réponds : « Bien. Faisons-en un spike, et revenez avec une recommandation. » L'élément est estimé comme un spike, ou il retourne dans la file jusqu'à ce que le spike soit terminé.

Les estimations sans user story

Estimer un élément qui n'a ni user story ni critères d'acceptation est hors limites. Le chiffre ne repose sur rien, et les estimations provisoires ont la fâcheuse habitude d'être ressorties à l'équipe des mois plus tard comme des engagements. Si quelqu'un demande « est-ce qu'on peut juste mettre un chiffre approximatif ? », la réponse est de le renvoyer aux critères d'entrée.

Les débats sur la roadmap et les priorités

Quoi construire au trimestre prochain, faut-il changer de stratégie, cette fonctionnalité compte-t-elle seulement : ce sont des conversations de la direction et du PO qui ont lieu en dehors de l'affinage. La séance accepte l'ordre de priorité que le PO a apporté dans la salle. Si un développeur pense que l'ordre est mauvais, c'est une préoccupation légitime, et elle va au parking avec le PO comme responsable au lieu d'être débattue pendant 20 minutes pendant que la file attend.

Les habitudes d'animation qui tiennent le déroulé

Désignez un animateur qui ne représente pas aussi les priorités du PO ou les points de vue techniques des développeurs. C'est souvent le Scrum Master, mais un développeur tournant fonctionne si le Scrum Master est trop proche du contenu. Quelqu'un qui se dispute sur le périmètre ne peut pas, de manière crédible, faire respecter une timebox sur les disputes de périmètre.

Rappelez le déroulé et la règle de ce qui est hors périmètre au début de chaque séance, y compris la quarantième. Cela paraît répétitif, mais cela donne à l'animateur la légitimité sociale d'interrompre à la minute 22 sans paraître arbitraire, parce que le groupe a accepté la règle vingt minutes plus tôt.

Projetez le déroulé ou gardez-le ouvert dans un onglet partagé pour les séances à distance. Les équipes qui mènent l'affinage de mémoire connaissent bien plus de moments « attendez, qu'est-ce qu'on fait là ? » que celles qui voient le bloc en cours et le minuteur. Mon guide précédent sur comment animer une séance d'affinage du backlog efficace traite plus en détail de l'installation à distance.

Terminez par un récapitulatif écrit : quels éléments sont désormais prêts, lesquels ont été découpés et en quoi, lesquels ont été renvoyés et pourquoi, et ce qui est au parking et sous la responsabilité de qui. Le PO met à jour le backlog à partir de ce récapitulatif dans l'heure, tant que les décisions sont fraîches.

Traitez le déroulé comme une discipline et appliquez-le tel quel pendant trois sprints

La structure de 60 minutes et la règle de ce qui est hors périmètre protègent l'attention de l'équipe pour la seule chose à laquelle sert l'affinage : rendre prêts les prochains éléments. Les timebox paraîtront serrées lors de la première séance, et quelqu'un demandera plus de temps pour un élément qui le mérite. Mettez-le quand même au parking et tenez la structure.

Avant votre prochaine séance, asseyez-vous avec l'équipe pour rédiger ou mettre à jour votre Definition of Ready, puis utilisez le guide de l'affinage du backlog pour adapter les critères d'entrée à votre contexte. Ensuite, appliquez ce déroulé exactement tel qu'il est écrit pendant trois sprints. Suivez combien d'éléments sortent prêts de chaque séance et quelle part de la sprint planning est consacrée à de l'affinage improvisé. Seulement alors, ajustez les timebox, et modifiez un bloc à la fois pour pouvoir savoir ce qui a fait la différence.