La réunion d'affinage du backlog, aussi appelée session d’affinage du carnet de produit ou backlog refinement meeting, désigne une activité récurrente des projets agiles, principalement en Scrum, durant laquelle l’équipe produit examine, détaille, estime et ordonne les éléments du carnet de produit. Contrairement aux événements formels prescrits par le cadre Scrum, ce temps de travail ne possède pas de caractère obligatoire, mais il constitue une pratique quasi universelle pour garantir que le backlog reste un outil de pilotage fiable et non une simple liste de souhaits. Son intention est de faire passer des exigences de haut niveau, souvent floues, à un état de préparation suffisant pour que les sprints à venir puissent les intégrer sans ralentir le flux de développement.
Tableau récapitulatif de la réunion d'affinage du backlog
| Concept | Résumé |
|---|---|
| Définition fondamentale | Activité itérative au cours de laquelle l’équipe Scrum décortique, précise les critères d’acceptation, estime l’effort et réordonne les éléments du Product Backlog afin de les rendre immédiatement exploitables pour les sprints à venir. |
| Caractère obligatoire | Bien que le Scrum Guide n’en fasse pas un événement formel, cette pratique s’impose comme une condition de maturité quasi universelle ; sans elle, le backlog devient rapidement inexploitable en planification de sprint. |
| Finalité opérationnelle | L’objectif est de réduire l’incertitude et l’ambiguïté en transformant des besoins généraux en items suffisamment affinés pour que l’équipe puisse s’engager en toute confiance, alignés sur une définition de « prêt » partagée. |
| Évolution terminologique | Le terme anglais « grooming », initialement employé, a été abandonné au profit de « refinement » (affinage) par le Scrum Guide 2020 afin de supprimer toute connotation négative, notamment dans les contextes liés à la protection de l’enfance. |
| Collaboration croisée | Le Product Owner apporte la vision métier, les développeurs évaluent la faisabilité technique et les parties prenantes clés injectent leur expertise. Cette triangulation systématique limite les malentendus et les écarts fonctionnels. |
| Racines historiques | Issue des « planning games » de l’eXtreme Programming et des premières implémentations Scrum chez Easel Corporation en 1993, cette pratique répondait déjà au besoin de maintenir un carnet de produit continuellement viable. |
| Modalités de mise en œuvre | On observe deux grandes approches : une session planifiée, souvent limitée à environ 10 % de la capacité du sprint, et un affinage continu asynchrone déclenché par les échanges techniques. Les équipes matures articulent les deux pour une réactivité maximale. |
| Équilibre des responsabilités | L’enjeu est de confier à l’équipe la maîtrise du « comment » sans empiéter sur la prérogative du Product Owner à décider le « quoi ». Un affinage sain préserve cette frontière, le PO restant seul habilité à modifier les priorités métier. |
Définition et place dans les cadres agiles
Dans la terminologie officielle du Scrum Guide, il est simplement question de « Product Backlog refinement », sans imposer de format particulier. En français, la définition de la réunion d’affinage du backlog renvoie à un espace de collaboration où le Product Owner, les développeurs et éventuellement des parties prenantes réduisent l’incertitude entourant les futurs éléments du travail. Il ne s’agit pas d’une cérémonie de décision formelle comme la planification de sprint, mais d’un moment d’exploration et de clarification qui prépare le terrain pour que la planification soit rapide et efficace. La pratique a longtemps été nommée « grooming » dans la communauté anglophone, terme que le Scrum Guide 2020 a délibérément écarté en raison de connotations négatives, pour lui préférer « refinement », plus neutre.
L’affinage se distingue des rétrospectives, des revues de sprint ou des mêlées quotidiennes par son caractère prospectif orienté vers le contenu du produit. Alors qu’une mêlée quotidienne synchronise le travail en cours, l’affinage questionne ce qui arrivera dans un futur proche, souvent à l’horizon d’un à trois sprints. On peut le voir comme le moment où l’équipe passe d’une vision macro du produit, portée par la feuille de route, à une granularité suffisante pour qu’un item puisse être sélectionné en toute confiance. Cette transformation progressive évite la surspécification prématurée, un écueil classique des méthodes prédictives.
Origine et évolution du terme
L’idée d’affiner périodiquement la liste des travaux à faire trouve ses racines dans les premières implémentations de l’eXtreme Programming et de Scrum à la fin des années 1990. Les équipes constataient que bâtir un plan complet dès le départ menait à un gaspillage d’effort considérable, car les besoins changeaient. À la place, elles ont commencé à décomposer les fonctionnalités juste avant leur développement, en sessions informelles souvent appelées « backlog grooming ». L’image évoquait le toilettage d’un animal : on entretient et on prépare le backlog pour qu’il reste sain. Avec le temps, la communauté agile a reconnu que la métaphore n’était pas des plus heureuses et que l’« affinage » décrivait mieux l’activité intellectuelle de préciser, découper et estimer les exigences.
Dans la pratique contemporaine, l’affinage du backlog n’est plus considéré comme une réunion optionnelle que l’on tient « quand on a le temps », mais comme une discipline continue. Certaines équipes réservent un créneau fixe dans la semaine, tandis que d’autres fractionnent l’effort en micro-sessions liées aux discussions techniques spontanées. Le Scrum Guide reste silencieux sur la durée et la fréquence, ce qui permet une adaptation contextuelle poussée.
Principales caractéristiques
Une réunion d’affinage typique ne se limite pas à lire à voix haute la liste du backlog. Elle combine analyse fonctionnelle, décomposition technique, estimation relative, réorganisation des priorités et identification des dépendances. L’équipe examine chaque élément en se posant des questions comme « Que signifie exactement cette fonctionnalité ? », « Comment vérifier qu’elle est terminée ? », ou « Quelle est sa taille par rapport à ce que nous avons déjà livré ? ». Ces échanges produisent une compréhension partagée qui réduit les ambiguïtés et évite les blocages pendant le sprint.
Un trait fondamental est que la décision d’ajouter, de modifier ou de supprimer un élément du backlog reste du ressort du Product Owner. Les développeurs apportent leur expertise sur la faisabilité et l’effort, mais la priorisation finale relève de la valeur d’affaires. On touche ici à un équilibre délicat : l’équipe doit se sentir suffisamment impliquée pour s’approprier les items, sans déposséder le Product Owner de sa responsabilité sur le « quoi ».
L'essentiel sur l'affinage du backlog
- Définition officielle du Scrum Guide
- Le Scrum Guide désigne cette pratique sous le nom de « Product Backlog refinement », sans prescrire de format imposé : il s'agit d'un espace collaboratif où le Product Owner, les développeurs et les parties prenantes réduisent ensemble l'incertitude entourant les éléments à venir.
- Espace d'exploration et de clarification
- Contrairement à la planification de sprint, l'affinage ne constitue pas une cérémonie décisionnelle formelle, mais un temps d'exploration et de clarification qui rend la planification ultérieure plus rapide et plus efficace.
- Évolution terminologique du grooming
- La communauté anglophone a longtemps utilisé le terme « grooming », mais le Scrum Guide 2020 a expressément adopté « refinement » afin d'éviter les connotations péjoratives du terme précédent.
- Caractère prospectif et orienté contenu
- L'affinage se distingue des rétrospectives, des revues de sprint et des mêlées quotidiennes par sa focalisation prospective sur le contenu du produit : il examine les éléments susceptibles d'être développés dans un horizon de un à trois sprints.
- Origines dans les années 1990
- La pratique puise ses origines dans les premières implémentations d'eXtreme Programming et de Scrum, à la fin des années 1990, lorsque les équipes ont réalisé que planifier exhaustivement en amont gaspillait des efforts dans un contexte de besoins évolutifs.
Composantes clés et déroulement typique
Décrire les composantes clés d’une réunion d’affinage du backlog aide à ne pas confondre cette pratique avec une simple réunion de lecture. Chaque session repose sur un triptyque : les participants, les activités menées et le résultat attendu. Sans un cadrage minimal, une réunion d’affinage peut vite dériver vers du débat philosophique sans production concrète, ce qui frustre les équipes et érode la confiance dans le processus.
Participants et rôles
Le Product Owner est l’animateur naturel de la session, car il détient la vision du produit et la connaissance des besoins utilisateurs. Sa présence est indispensable pour répondre aux questions, trancher rapidement et ajuster les priorités en direct. Les développeurs, quant à eux, apportent le regard technique : ils signalent les risques, proposent des découpages alternatifs et fournissent des estimations. Le Scrum Master intervient moins dans le contenu que dans la facilitation : il veille à ce que le temps soit bien utilisé et à ce que les règles de collaboration soient respectées, par exemple en limitant les apartés hors sujet.
La question de la participation des parties prenantes externes divise les praticiens. Certaines équipes invitent ponctuellement un expert métier pour clarifier une règle de gestion complexe, d’autres préfèrent que le Product Owner couvre ce rôle seul, afin de protéger le temps de concentration des développeurs. Il n’existe pas de règle absolue ; l’essentiel est que chaque participant ajoute de la valeur réelle à la session.
Activités menées
L’ordre du jour n’est jamais formel, mais plusieurs actions reviennent de manière systématique. On commence souvent par reprendre les éléments en haut de la pile, ceux qui sont candidats aux prochains sprints. Le Product Owner rappelle rapidement le contexte, puis l’équipe s’attèle à clarifier les critères d’acceptation : une liste de conditions vérifiables qui, une fois toutes remplies, signifient que l’élément est terminé. Cette rédaction, même à l’état d’ébauche, est un puissant révélateur des malentendus. Si personne ne sait dire concrètement comment tester l’item, c’est qu’il n’est pas assez mûr.
Vient ensuite l’étape du découpage, ou « splitting ». Les éléments trop volumineux, souvent appelés épics, doivent être fractionnés en morceaux de plus petite taille, livrables en un sprint. Le découpage n’obéit pas qu’à des règles techniques ; une histoire utilisateur peut être scindée selon les cas d’usage, les profils d’utilisateurs ou les chemins fonctionnels (succès, erreur, cas limite). L’estimation, quant à elle, se fait presque toujours de manière relative, par exemple en utilisant le planning poker et une échelle comme la suite de Fibonacci. L’équipe compare l’effort d’un nouvel item à celui d’une référence établie, ce qui ancre l’estimation dans le concret et contourne les biais de l’évaluation en heures à un stade trop précoce.
Fréquence et durée
La fréquence idéale dépend du contexte, mais la plupart des équipes consacrent entre une et deux heures par semaine à l’affinage, souvent en milieu de sprint pour ne pas perturber le démarrage ni la revue. Certaines préfèrent une session unique de deux heures en deuxième moitié de sprint, d’autres éclatent l’exercice en trois créneaux de quarante minutes. L’important est de maintenir une cadence régulière et un stock tampon d’items prêts, correspondant à peu près au contenu d’un à deux sprints. Consacrer trop peu de temps fait courir le risque de démarrer le sprint avec des éléments flous, ce qui provoque des blocages et des discussions interminables en cours de sprint. À l’inverse, un affinage excessif sur des items lointains crée du surmenage intellectuel et du gaspillage, car les priorités auront probablement changé d’ici là.
L’affinage du backlog selon les référentiels projet
Comprendre l’affinage du backlog dans le PMBOK et les autres cadres méthodologiques permet de situer cette pratique au-delà de Scrum. Bien que la réunion d’affinage soit un enfant naturel des méthodes agiles, des principes analogues se retrouvent dans les référentiels classiques lorsqu’ils abordent la planification adaptative et la gestion continue des exigences.
Perspective PMBOK
Le PMBOK, dans sa septième édition, reconnaît explicitement l’existence du carnet de produit comme artefact des environnements adaptatifs. Plusieurs processus du domaine de la planification y trouvent des correspondances. L’affinage du backlog peut ainsi être vu comme une incarnation de l’activité « Élaborer le contenu du projet », combinant des pratiques de recueil d’exigences, de définition du périmètre et de création de la structure de découpage du travail, mais selon une logique itérative et « juste à temps ». Plutôt que de livrer un cahier des charges figé, l’équipe affine par vagues successives.
Dans la terminologie du PMBOK 6, on pouvait rapprocher l’affinage du processus « Recueillir les exigences » tout en y intégrant des éléments de « Définir le contenu » et « Créer le WBS ». La différence fondamentale tient au caractère continu et émergent du raffinement : le WBS prédictif cherche à être exhaustif dès le départ, alors que le backlog vise une granularité suffisante pour le seul prochain incrément de travail. Cette divergence explique pourquoi les chefs de projet formés au prédictif peuvent être déconcertés par une réunion d’affinage : ils y cherchent un plan complet, alors qu’elle ne fournit qu’une clarification progressive.
Place dans PRINCE2 Agile
PRINCE2, dans sa version classique, ne mentionne pas de réunion d’affinage du backlog. Toutefois, la déclinaison PRINCE2 Agile intègre pleinement les concepts agiles et reconnaît le backlog comme un registre des exigences évolutif. Dans ce cadre, l’affinage s’inscrit dans les activités de gestion de la livraison de produit, en lien avec l’élaboration des descriptions de produits détaillés. La philosophie PRINCE2 consistant à « gérer par exceptions » et à maintenir un focus sur la justification continue de l’affaire trouve un écho dans la pratique du raffinement : il ne s’agit pas seulement de rendre un item assez clair pour le développement, mais aussi de vérifier qu’il sert toujours la justification du projet, une question que le Product Owner doit garder en tête.
Synthèse sur l'affinage du backlog
- Affinage au-delà de Scrum
- L'affinage ne se limite pas au monde agile ; le PMBOK septième édition reconnaît explicitement le carnet de produit comme un artefact incontournable des approches adaptatives, ce qui en étend la pertinence.
- WBS prédictif versus backlog
- Le WBS prédictif vise une couverture exhaustive dès le lancement, alors que le backlog se concentre uniquement sur la granularité requise pour l'incrément à venir ; cette divergence est source de confusion pour les chefs de projet venus du prédictif.
- PRINCE2 Agile et justification continue
- PRINCE2 Agile positionne le backlog comme un registre d'exigences évolutif ; lors de l'affinage, on vérifie que chaque item contribue toujours à la justification continue de l'affaire, ce qui représente un enjeu critique pour le Product Owner.
Approche BVOP et affinage du backlog
La méthodologie Business Value-Oriented Project Management (BVOPM) propose un regard spécifique sur l’affinage du backlog en mettant l’accent sur la préservation de la valeur d’affaires et l’élimination du gaspillage. La vision BVOP de l’affinage du backlog place la mesure de la valeur au cœur de la discussion, avec des principes qui enrichissent la pratique sans la contredire. Ainsi, BVOPM recommande une estimation à l’aide de points d’effort relationnels plutôt que des durées absolues, ce qui rejoint le recours commun au planning poker, mais en insistant sur la comparaison explicite avec des items de référence déjà livrés. Ce mimétisme des pratiques agiles n’est pas fortuit ; il garantit que l’effort estimé reste corrélé à la valeur perçue et non à une tentation de « gonfler » les estimations.
Un apport distinctif de BVOPM concerne le traitement des modifications du périmètre. La méthode définit une échelle de cinq niveaux de certitude pour les éléments du backlog, allant de « Défini » à « Improbable ». Dans ce modèle, l’affinage contribue à faire glisser les items vers la catégorie Défini, tandis que les changements de priorité sont interprétés comme des retours d’information légitimes et non comme des échecs de planification. Une telle posture réduit la tension souvent observée entre le Product Owner, qui ajuste le carnet en fonction du marché, et l’équipe, qui peut ressentir une instabilité frustrante. En institutionnalisant le caractère mouvant du backlog, BVOPM invite les équipes à ne pas sacraliser le plan initial et à considérer l’affinage comme un processus permanent d’adaptation à la valeur.
Défis, pièges et idées reçues
Malgré sa simplicité apparente, la réunion d’affinage concentre un nombre surprenant de difficultés opérationnelles. Les pièges de la réunion d’affinage du backlog sont rarement techniques ; ils relèvent le plus souvent de la dynamique d’équipe, de la perception du temps perdu et de la confusion entre préparation et décision.
Un écueil classique est la transformation de l’affinage en une pseudo-planification de sprint anticipée. L’équipe, cherchant à sécuriser le prochain sprint, commence à attribuer des tâches et à définir un plan d’exécution détaillé pour des items qui n’ont pas encore été officiellement sélectionnés. Ce comportement crée un engagement implicite et une rigidité qui contredisent l’adaptabilité agile. Le Product Owner peut alors se sentir prisonnier d’un plan que l’équipe a déjà « prémâché », rendant difficile tout changement de priorité de dernière minute.
Un autre travers fréquent est l’absence de temps dédié. Les organisations qui traitent l’affinage comme une activité « par-dessus le marché » finissent par accumuler un backlog obèse, peuplé d’items vagues et jamais revus. Le résultat est une planification de sprint laborieuse, où l’équipe passe la moitié de la réunion à improviser un découpage et à débattre de définitions, faute d’avoir préparé le terrain. À terme, cette négligence érode la vélocité et la qualité des livraisons, car les items insuffisamment affinés sont souvent porteurs de défauts ou d’incompréhensions qui explosent en cours de sprint.
Du côté des idées reçues, beaucoup pensent que l’affinage est une formalité administrative réservée au Product Owner. En réalité, l’absence des développeurs vide la réunion de sa substance technique : sans leur regard, les estimations restent décorrélées du réel et les dépendances architecturales passent inaperçues. Une autre méprise commune consiste à croire qu’il faut affiner l’intégralité du carnet avant le premier sprint, héritage inconscient des cultures prédictives où l’exhaustivité est une vertu. Sur un plan d’affaires sain, cette approche aboutit à un gaspillage massif, car une partie des items affinés en détail ne verra jamais le jour.
Il arrive aussi que l’équipe confonde affinage et entretien du backlog (backlog management). L’affinage porte sur le contenu, la clarté et la taille des items, tandis que l’entretien englobe le nettoyage des éléments obsolètes, la réorganisation structurelle et l’alignement stratégique. Sans un entretien régulier, le backlog devient un cimetière d’idées mortes qui parasite les séances d’affinage. Les équipes efficaces réservent un court moment, souvent avec le seul Product Owner, pour ce nettoyage en amont.
Défis et erreurs à éviter
- Confusion entre préparation et décision
- L’équipe répartit les tâches avant la planification officielle du sprint, ce qui contraint le Product Owner à un plan préétabli et limite sa capacité à réorienter les priorités en fonction des retours.
- Affinage négligé et backlog obèse
- Considérer l’affinage du backlog comme une tâche secondaire génère des user stories imprécises, alourdit la charge des sprints et dégrade à la fois la vélocité et la qualité des livrables.
- Idées reçues sur le périmètre
- La non-participation des développeurs aux ateliers d’affinage aboutit à des estimations déconnectées du terrain, tandis que la volonté de tout spécifier à l’avance relève d’une logique prédictive incompatible avec l’agilité.
Relations avec d’autres concepts de gestion de projet
Une compréhension précise de l’affinage du backlog par rapport à la planification de sprint et aux autres cérémonies agiles évite les doublons et clarifie les responsabilités. La planification de sprint a pour objet de sélectionner un sous-ensemble d’items du backlog et de concevoir un plan de réalisation pour l’incrément à venir, tandis que l’affinage intervient en amont, à titre préparatoire. Si la planification de sprint était le moment de garnir une casserole, l’affinage serait l’étape où les ingrédients ont déjà été triés, lavés et coupés. Cette métaphore culinaire a ses limites, mais elle souligne la fonction de pré-conditionnement : on ne prend pas de décision irrévocable lors de l’affinage, on facilite simplement la prise de décision ultérieure.
L’affinage interagit également avec la définition de prêt (Definition of Ready, DoR). Bien que la DoR ne soit pas un concept officiel du Scrum Guide, beaucoup d’équipes l’utilisent comme liste de contrôle pour déterminer si un item est suffisamment mûr pour être intégré dans un sprint. La réunion d’affinage est le lieu naturel où l’on vérifie, voire où l’on coconstruit, cette maturité. Par extension, les critères d’acceptation précisés en affinage nourrissent la définition de fini (Definition of Done) appliquée pendant le sprint, même si la DoD englobe des aspects plus transversaux comme les tests non fonctionnels et la documentation.
Comparé à la mêlée quotidienne, l’affinage opère sur un horizon temporel différent : la mêlée se focalise sur les vingt-quatre heures à venir et les blocages immédiats, alors que l’affinage porte sur les deux à six semaines à venir. Les deux se complètent sans se chevaucher. Une confusion courante chez les jeunes équipes agiles consiste à profiter de la mêlée pour lancer des débats de fond sur des items futurs, ce qui allonge la réunion et détourne son objectif de synchronisation rapide. Le rôle du Scrum Master est alors de rappeler que ce type de discussion appartient à l’affinage.
Dans le champ plus large du management de programme, l’affinage du backlog contribue indirectement à la gestion des dépendances inter-équipes. Lorsque plusieurs équipes travaillent sur un produit commun ou des composants liés, une session d’affinage conjointe, ou « scrum of scrums » appliqué au backlog, permet de détecter les collisions architecturales et d’aligner les calendriers de raffinement. Cette pratique n’est pas systématique, mais elle s’avère précieuse dans les contextes de mise à l’échelle où un backlog unique de programme doit être fragmenté en carnets d’équipe synchronisés.
Évolution et pratiques contemporaines
L’évolution de la réunion d’affinage du backlog a accompagné la maturation des approches agiles et l’apparition de nouveaux modèles de collaboration, en particulier le travail à distance. L’époque où l’affinage se déroulait exclusivement autour d’un tableau blanc physique est révolue ; désormais, les outils de gestion de backlog en ligne comme Jira, Azure DevOps ou Trello intègrent des fonctionnalités collaboratives qui transforment la mécanique d’affinage. Les équipes peuvent commenter, voter et estimer de manière asynchrone avant la session, ce qui réserve le temps synchrone aux échanges à forte valeur ajoutée, comme les débats de priorisation ou les arbitrages architecturaux.
Une tendance récente consiste à dissocier l’affinage fonctionnel de l’affinage technique. L’affinage fonctionnel, piloté par le Product Owner, se concentre sur la valeur métier et les cas d’usage. L’affinage technique, lui, réunit les développeurs et les architectes pour décomposer les items en tâches techniques, repérer les besoins de refactoring et évaluer les impacts sur la base de code. Cette segmentation, bien qu’elle puisse paraître lourde, est parfois adoptée dans des contextes très complexes où le domaine métier et les contraintes techniques exigent une expertise distincte. Elle ne convient cependant pas aux petites équipes, qui préfèrent une session unifiée pour éviter les pertes de contexte.
Le débat sur la place des estimations dans l’affinage reste vif. Le courant #NoEstimates remet en question l’utilité de toute estimation, y compris relative, arguant qu’une bonne décomposition en items de taille uniforme suffit pour la prévisibilité. Les défenseurs du planning poker rétorquent que l’estimation d’équipe révèle des divergences de compréhension bien plus que des chiffres prédictifs. La pratique dominante consiste à ne pas abandonner l’estimation, mais à la traiter comme un sous-produit de la discussion, jamais comme une fin en soi. L’important est que l’équipe se parle ; la note d’effort n’est qu’un résidu de cette conversation.
Enfin, les grandes organisations qui naviguent entre agilité et gouvernance classique ont développé des variantes hybrides du raffinement. Elles conservent un backlog agile pour les équipes de réalisation, mais ajoutent une couche de traçabilité vers les exigences contractuelles ou réglementaires. Dans de tels environnements, la réunion d’affinage peut inclure une vérification rapide de la correspondance avec les spécifications validées par le client, sous peine de non-conformité. Cette adaptation pragmatique montre que le principe d’affinage n’est pas rigide : il peut être injecté dans des cultures projet très différentes, à condition d’en préserver l’esprit de clarification continue et de réduction des risques.
Essentiel de l'affinage contemporain
- Outils numériques collaboratifs
- Les plateformes telles que Jira, Azure DevOps ou Trello dépassent le simple remplacement des tableaux blancs : elles instaurent un espace de travail partagé où la co-construction du backlog devient continue et transparente, modifiant profondément la dynamique d’affinage.
- Préparation asynchrone des sessions
- Le commentaire, le vote et l’estimation préalables en mode asynchrone libèrent le temps synchrone pour des échanges à forte valeur ajoutée, tels que les débats de priorisation et les arbitrages architecturaux.
- Séparation des affinages fonctionnel et technique
- De plus en plus, on distingue un affinage fonctionnel piloté par le Product Owner, focalisé sur la valeur métier et les cas d’usage, d’un affinage technique conduit par les développeurs et les architectes.
- Affinage technique orienté code
- L’affinage technique mobilise les développeurs et les architectes pour découper les items en tâches techniques, repérer les besoins de refactoring et anticiper l’impact sur la base de code, particulièrement dans les contextes de forte complexité logicielle.
- Débat sur la valeur des estimations
- Certains considèrent que des items de taille comparable suffisent à garantir la prévisibilité, rendant l’estimation superflue, tandis que les défenseurs du planning poker insistent sur sa capacité à révéler les incompréhensions et à aligner l’équipe.
