De la piscine à l’eau libre : pourquoi le No Estimate se mérite

“Be water, my friend.” — Bruce Lee

On parle beaucoup du No Estimate. On parle beaucoup du Kanban. On parle moins de ce qu’il faut comprendre avant d’y arriver.

Pendant des années, les équipes ont estimé. En story points, en jours idéaux, en t-shirts. Et progressivement, l’estimation est devenue un rituel — une réunion de plus, une friction de plus, une promesse qu’on savait impossible à tenir mais qu’on reconduisait quand même, sprint après sprint.

Alors quand le mouvement No Estimate a émergé, beaucoup y ont vu une libération. Arrêtons d’estimer. Regardons le flux. Mesurons le throughput — le nombre de sujets réellement livrés par unité de temps. La prédictibilité viendra d’elle-même.

Sauf que ce n’est pas aussi simple.

Le No Estimate n’est pas un raccourci. C’est la conséquence possible d’un système devenu lisible — une équipe qui a d’abord appris à se lire elle-même, sa vélocité, ses limites, la forme de son flux, et qui peut maintenant s’en affranchir parce qu’elle a compris pourquoi elle estimait.

Cet article ne prend pas parti pour le Scrum ou pour le Kanban. Il essaie de mettre chaque chose à sa place : ce que l’estimation enseigne, ce que le flux révèle, et comment on passe de l’un à l’autre sans perdre ce qu’on avait appris. Avec, en fil rouge, une seule question : qu’est-ce qui rend une équipe prédictible — et comment voir vite quand elle cesse de l’être ?

Pourquoi on estime — et pourquoi ça devient un piège

L’estimation en Scrum est un outil de lecture. Pas une vérité. Pas un engagement. Une boussole.

Quand une équipe commence à travailler en sprint, elle apprend à peser ses sujets. Un story point ne mesure pas le temps — il mesure l’effort relatif d’un sujet par rapport à un autre. Et l’effort, ce n’est pas que la complexité : c’est aussi le volume de travail et le risque. Un sujet trivial mais long à saisir pèse lourd sans être compliqué. Progressivement, en observant combien de points elle livre réellement chaque sprint, l’équipe construit sa vélocité. Elle apprend à se connaître.

C’est précisément là l’intérêt du Scrum : forcer une équipe à calibrer sa propre capacité. Pas celle qu’elle croit avoir. Celle qu’elle démontre semaine après semaine.

En piscine, les lignes d’eau délimitent votre couloir. C’est artificiel. Contraignant, parfois frustrant. Mais c’est précisément cette contrainte qui apprend à nager droit.

Puis vient le moment où l’outil devient la fin. L’estimation n’est plus un moyen de progresser — elle devient un rituel défensif, une couverture contractuelle, une source de friction entre business et technique. L’équipe estime pour rassurer, pas pour prédire.

L’estimation n’est pas le problème. Le problème commence quand elle devient une promesse.

C’est là que naît l’envie de passer à autre chose.

Le Kanban comme modèle de flux continu

Imaginez une chaîne de production dans une usine. Les pièces entrent, avancent de poste en poste, sortent transformées. Personne ne “planifie” combien de pièces vont rentrer ce mardi matin — on pilote le flux. On surveille les goulots. On ajuste la cadence à la capacité réelle du système.

Le Kanban s’inspire de cette logique. Une équipe n’est plus une boîte qui “consomme des points” sur deux semaines. C’est un système de production dans lequel les sujets circulent. Ce qui compte, ce n’est plus “combien ça va prendre” mais “comment le flux se comporte”.

Mais attention : le Kanban ne se contente pas de regarder le flux. Il le contraint. Son mécanisme central, ce sont les limites de travail en cours — les limites WIP. On décide qu’un état ne peut pas contenir plus de N sujets à la fois. Et cette contrainte change tout : quand une colonne est pleine, on ne peut plus y pousser de nouveau sujet. Il faut d’abord en faire sortir un. L’équipe est forcée de finir avant de commencer, de résoudre le goulot avant de l’alimenter. Sans limite WIP, le Kanban n’est qu’un tableau joli. Avec, il devient un système qui se régule.

L’outil principal pour lire ce comportement ? Le Diagramme de Flux Cumulé — le CFD.

Ce graphique empilé montre, au fil du temps, combien de sujets se trouvent dans chaque état du flux : backlog, en cours, en review, livré. Une courbe saine progresse de façon régulière et parallèle pour chaque état. Dès qu’une bande s’élargit — qu’un état “gonfle” — c’est un signal : quelque chose ralentit. Les sujets s’accumulent quelque part. Le flux se déforme.

Et c’est là l’un des diagnostics les plus puissants du Kanban.

Si le nombre de sujets qui entrent dépasse régulièrement le nombre de sujets qui sortent, c’est un signal. Pas forcément que l’équipe est trop petite — ça peut être une limite WIP absente ou trop large qui laisse tout entrer, un goulot en review, des dépendances externes qui bloquent la sortie, un processus de validation trop lourd. Le CFD montre le symptôme. L’interprétation demande une analyse. Mais il le montre avant que quiconque ose le formuler en réunion.

Et ça, c’est déjà beaucoup.

Exemple concret. Une équipe livre en moyenne 8 tickets par semaine. Pendant trois semaines, elle en fait entrer 14. La review reste correcte — quelques sujets sortent toujours. Mais le CFD, lui, montre que la bande “In Progress” gonfle, semaine après semaine. Le problème n’est pas visible uniquement dans ce qui sort. Il est visible dans ce qui s’accumule. Et selon les autres métriques — cycle time, WIP, taille des sujets — on comprend si c’est un problème de capacité, de goulot, ou de découpage.

Lire un CFD, c’est apprendre à lire les courants. Pas juste regarder si l’eau bouge.

Ce que le CFD dit que votre sprint review ne dira pas. La sprint review montre ce qu’on a livré. Le CFD montre comment le système se comporte. Ce sont deux lectures différentes de la même réalité. La première rassure ou inquiète sur la période écoulée. La seconde révèle les tendances structurelles : là où le flux se déforme, là où les sujets stagnent, là où la capacité est sous-dimensionnée. Une bande “In Progress” qui s’élargit semaine après semaine n’est pas un problème de sprint — c’est un problème systémique.

Ce que le flux cache, il finit toujours par le montrer.

Discovery et Delivery : ne jamais mélanger les eaux

Il y a une erreur structurelle qui ruine la prédictibilité d’un flux, et elle est presque toujours involontaire : faire cohabiter le Discovery et le Delivery dans le même workflow.

Ce ne sont pourtant pas deux étapes d’un même travail. Ce sont deux natures de travail, avec deux régimes complètement différents.

Le Delivery est borné. Un sujet bien découpé a un début, une fin, une fourchette de taille maîtrisée. C’est exactement ce qui rend le throughput prédictible.

Le Discovery, lui, est non borné par essence. Explorer, comprendre, lever une incertitude, cadrer un besoin flou — ça peut prendre une heure ou trois semaines, et c’est normal. On ne sait pas combien de temps il faut pour comprendre une chose qu’on ne comprend pas encore. Sinon, on l’aurait déjà comprise.

Le piège est là. Prenez une équipe qui ajoute une colonne “En affinage” au début de son board, juste avant le développement. L’intention est bonne : rendre visible le travail de clarification. Mais en plaçant cette colonne dans le flux de production, elle vient d’injecter du non-borné dans un système qu’elle essaie justement de garder borné.

Les conséquences sont directes. La distribution des tailles devient instable, puisqu’on mélange des sujets calibrés et des explorations sans limite. Le CFD devient illisible : la bande “affinage” gonfle, mais pour des raisons saines — l’exploration prend le temps qu’elle prend. Et l’outil ne sait plus distinguer une dérive d’une exploration normale. Le détecteur de dérive se met à sonner pour rien. Ou pire : il ne sonne plus quand il le faudrait, parce qu’on s’est habitué à le voir clignoter.

C’est exactement le monstre non borné dont on parlait — mais structurel cette fois. Vous ne l’avez pas laissé entrer par accident. Vous lui avez construit une colonne.

La règle est simple : le Discovery doit vivre en dehors du flux de production. Dans un autre board, un autre rythme, une autre manière de mesurer. Pas parce que le Discovery n’a pas de valeur — au contraire, c’est lui qui produit les sujets bien bornés qui alimenteront le Delivery. Mais parce que mélanger les deux, c’est mélanger l’eau de l’exploration et l’eau de la production dans le même bassin. Les deux sont nécessaires. Aucune ne se mesure de la même façon.

Une fois les eaux séparées, le flux de Delivery redevient ce qu’il doit être : un système borné, lisible, prédictible. Et le Discovery peut respirer à son propre rythme, sans polluer la lecture de la production ni en subir la pression.

La charge cognitive ne disparaît pas — elle se déplace

C’est l’argument qu’on entend le plus souvent pour justifier le passage au No Estimate : “l’estimation est une charge cognitive inutile.” Et c’est vrai — en partie.

Le planning poker prend du temps. Il génère des débats parfois stériles. Il crée l’illusion d’une précision qu’on n’a pas. Tout ça est réel.

Mais voilà ce qu’on dit moins : supprimer l’estimation ne supprime pas la charge cognitive. Elle la déplace.

En Kanban, en No Estimate, la charge se déplace sur le découpage. Au lieu de peser un sujet en points lors d’une réunion, l’équipe doit s’assurer — en amont, en continu — que chaque sujet est suffisamment petit, suffisamment précis, suffisamment autonome pour entrer dans le flux sans créer de turbulence. C’est une compétence différente, mais une compétence exigeante. Elle demande de la rigueur dans l’expression du besoin, de la conversation entre PO et équipe, et souvent plus de travail préparatoire que le planning poker n’en demandait.

La charge change de forme et change de moment. Elle passe de la réunion d’estimation à l’atelier de découpage — et elle produit quelque chose de plus utile : un sujet mieux compris, mieux borné, plus adressable. Mais elle ne disparaît pas.

Et l’étiquette sans découpage, ce n’est pas une solution. C’est une tentation réelle. Coller une étiquette de taille sur un ticket sans vraiment le découper, en se disant “de toute façon ça colle rarement à la réalité du code, alors autant ne pas se prendre la tête.” Ça ressemble à du pragmatisme. C’est en réalité un placebo.

Si vous mettez M sur un sujet qui est en réalité un XXL mal découpé, vous n’avez pas réduit la complexité — vous l’avez cachée. Le CFD va le montrer : ce ticket restera “In Progress” deux fois plus longtemps que les autres, il gonflera la bande, il faussera le throughput. L’étiquette ne change pas la réalité du flux.

Le throughput ne fonctionne comme outil de prédiction que si la distribution des tailles reste stable dans le temps. Attention : ça ne veut pas dire que tous vos sujets doivent faire la même taille. Vous pouvez mélanger des petits et des gros — tant que le mélange reste à peu près constant d’une semaine sur l’autre, la moyenne garde sa valeur prédictive. Ce qui tue la prédiction, ce n’est pas la variété des tailles. C’est l’imprévisibilité : un ticket monstre qui débarque sans qu’on l’ait vu venir, un sujet sans borne supérieure qui dévore trois semaines au lieu de trois jours. C’est ça qui fait exploser votre moyenne et la vide de tout sens.

La vraie question n’est pas “quelle taille je mets” — c’est “est-ce que ce sujet est prêt à entrer dans le flux.” C’est un critère de qualité du backlog. Et c’est exactement là que la charge cognitive doit s’exercer.

No Estimate : une libération qui se mérite

“No Estimate” est souvent mal compris. On l’entend comme : “on n’estime plus rien, on verra bien.” C’est l’opposé de ce que le mouvement propose.

Le No Estimate, c’est le pari que si les sujets sont suffisamment petits et que leur taille reste dans une fourchette maîtrisée, leur valeur exacte cesse d’être un facteur discriminant. Dix petits sujets bien découpés avancent de façon aussi prévisible que dix sujets à cinq points chacun — sauf qu’on n’a pas perdu deux heures à les chiffrer.

L’analogie qui fonctionne bien : pensez à une équipe de relais. Personne ne chronomètre chaque nageur isolément avant de plonger. Les distances sont fixées, les passages de relais répétés, les rôles connus. La prédictibilité de l’équipe ne vient pas de l’estimation de chaque longueur — elle vient d’un système rodé où chaque portion ressemble à la précédente.

Pour qu’une équipe atteigne ce niveau, trois conditions doivent être réunies.

Réduire la charge cognitive par sujet. Un sujet trop large génère des inconnues cachées. Plus un sujet est précis dans son expression, plus il est adressable sans friction. Le découpage n’est pas une contrainte bureaucratique — c’est ce qui rend les sujets nageables. Un bon ticket, c’est une longueur de bassin : un départ, une arrivée, une distance connue.

Stabiliser la distribution des tailles. L’enjeu n’est pas que tous les sujets soient identiques — c’est que leur répartition reste régulière dans le temps, et surtout qu’aucun monstre ne se faufile sans borne. Quand la distribution est stable, la moyenne devient une prédiction fiable. C’est le principe derrière le throughput : en mesurant combien de sujets une équipe livre par semaine sur les dernières semaines, on peut projeter avec une bonne fiabilité ce qui sera livré dans N semaines — sans une seule estimation.

Construire la capacité à prédire dans la durée. La prédictibilité n’est pas un état qu’on atteint — c’est une compétence qu’on développe. Plus une équipe est régulière dans son découpage, plus ses projections deviennent précises. Et plus ses projections sont précises, plus elle peut s’engager sereinement avec le business, sans sur-promettre ni sous-estimer.

La prédictibilité, le vrai sujet

Reculons d’un pas. Pourquoi tout ça ?

Pourquoi estimer, pourquoi observer le flux, pourquoi découper, pourquoi mesurer le throughput ? Il y a une réponse unique derrière toutes ces pratiques. Et c’est elle, le vrai sujet : la prédictibilité.

Une équipe prédictible, ce n’est pas une équipe rapide. C’est une équipe sur laquelle on peut s’appuyer. Une équipe qui, quand elle annonce « ce sera livré dans trois semaines », a une chance réelle d’avoir raison. C’est ça que le business attend — pas de la vitesse, de la fiabilité.

Et c’est là que tout se relie. L’estimation Scrum et le No Estimate ne sont pas deux camps opposés : ce sont deux moyens de servir la même fin. L’un construit la prédictibilité par le calibrage répété de la capacité. L’autre l’obtient par une distribution maîtrisée des tailles et l’observation statistique du flux. Deux chemins, une seule destination.

Mais la prédictibilité ne tombe pas du ciel. Elle repose sur une condition préalable, souvent négligée : la visibilité.

Une équipe ne peut pas devenir prédictible si elle ne se voit pas elle-même. C’est exactement le rôle du CFD, du cycle time, du throughput : rendre visible ce qui, sinon, resterait dans le ressenti. Et cette visibilité interne n’est pas d’abord un tableau de bord pour le management — c’est un outil de compréhension pour l’équipe. On ne pilote bien que ce qu’on voit clairement.

Voir clair sur son propre flux, c’est la première marche. Pouvoir prédire, c’est la seconde. L’une ne va pas sans l’autre.

Mais il y a une troisième marche, et c’est la plus importante. La prédictibilité n’est jamais acquise. Elle se dégrade en silence — un monstre qui se faufile dans le flux, une bande qui gonfle de quelques pourcents chaque semaine, un cycle time qui s’allonge sans qu’on le remarque. Une équipe vraiment mature n’est pas celle qui est prédictible un jour. C’est celle qui voit vite quand elle cesse de l’être. C’est là que la visibilité prend tout son sens : le CFD, le throughput, le cycle time ne sont pas des thermomètres qu’on regarde pour se rassurer. Ce sont des détecteurs de dérive. Leur valeur ne tient pas à ce qu’ils affichent quand tout va bien — elle tient à la vitesse avec laquelle ils sonnent l’alarme quand ça décroche.

Scrum d’abord, Kanban ensuite : une question de maturité

Il serait tentant de présenter le Kanban comme “plus avancé” que le Scrum — une évolution naturelle pour les équipes matures. Ce serait trop simple, et surtout trompeur.

Le Scrum a quelque chose que le Kanban seul ne donne pas : il force l’équipe à regarder en face sa propre capacité. Le sprint est une contrainte artificielle, certes — mais cette contrainte produit un apprentissage. L’équipe qui sur-engage sprint après sprint apprend que son optimisme systématique est un problème. Elle calibre. Elle ajuste. Elle développe un sens de son propre rythme.

Passer au Kanban sans avoir traversé cette phase, c’est apprendre à nager en eau libre avant d’avoir appris à nager en piscine. Le flux continu sans repère peut devenir une zone de confort où personne ne se demande jamais si l’équipe va dans la bonne direction.

La bonne séquence ressemble à ceci : comprendre le Scrum et ce qu’il enseigne sur la capacité réelle de l’équipe, puis internaliser le flux et apprendre à lire ce qui ralentit et ce qui gonfle, puis — si le contexte s’y prête — s’affranchir de l’estimation parce qu’on a compris pourquoi on estimait et qu’on peut maintenant obtenir la même prédictibilité autrement.

En pratique, beaucoup d’équipes matures ne choisissent pas entre les deux — elles mixent. Un cadre sprint pour le rythme collectif et les engagements vis-à-vis du business, un flux Kanban pour les sujets de support, de maintenance ou d’exploration. Ce n’est pas une contradiction. C’est une hybridation qui reconnaît que différents types de travail ont des natures différentes.

Et la maturité n’est pas que celle de l’équipe. Le sprint a une vertu qu’on oublie : il protège l’équipe des perturbations extérieures le temps d’un cycle. Le Kanban, lui, expose l’équipe au flux du monde réel en continu. Passer à un pilotage par le flux exige donc aussi une maturité des parties prenantes — un business qui accepte de ne plus pousser ses urgences n’importe quand, et de faire confiance à un système qui régule lui-même ses priorités. Sans ça, le flux se transforme en déversoir.

C’est ce moment — et seulement ce moment — où le No Estimate a du sens. Pas comme une économie de réunion. Comme une forme de confiance acquise.

Les signaux qui indiquent qu’on est prêt

La maturité ne se décrète pas. On ne décide pas un lundi matin de “passer au No Estimate”. On le constate — parce que certains signaux sont là.

La vélocité est stable depuis plusieurs sprints, sans efforts particuliers pour la maintenir. Le découpage est devenu un réflexe partagé : PO et équipe ont la même lecture de ce qu’est un sujet “prêt”. Le CFD est lisible — les bandes progressent de façon régulière, sans gonflements persistants. L’équipe sait lire son throughput et peut projeter une date de livraison sans passer par une session d’estimation.

Et surtout : l’équipe a arrêté d’estimer pour rassurer. Elle estime — ou elle n’estime plus — parce qu’elle comprend ce que ça lui apporte.

Quand ces signaux sont là, supprimer l’estimation ne change pas grand-chose au fond. C’est juste qu’on enlève un outil dont on n’avait plus vraiment besoin.

Pourquoi les équipes abandonnent le No Estimate trop tôt

Il y a des résistances réelles, et elles méritent d’être nommées.

Le PO veut des dates. C’est légitime — son rôle est de tenir des engagements vis-à-vis du business. La réponse n’est pas “faites-nous confiance”, c’est de montrer que le throughput donne une projection plus fiable qu’une estimation faite trois mois à l’avance. Les données parlent mieux que les points.

Le manager veut des commitments. Même logique. Un commitment basé sur un historique de flux est plus solide qu’un commitment basé sur du planning poker. Le No Estimate ne supprime pas l’engagement — il change la façon dont on le construit.

Le tech lead pense que l’estimation protège l’équipe. Parfois c’est vrai — l’estimation force une conversation sur la complexité avant de commencer. Mais cette conversation peut aussi avoir lieu lors d’un atelier de découpage. Ce n’est pas l’estimation qui protège l’équipe, c’est la qualité de la conversation en amont.

Ces résistances ne sont pas des obstacles idéologiques. Ce sont des besoins légitimes auxquels le No Estimate doit répondre — pas les ignorer.

L’autre boucle : livrer pour apprendre

Il reste une tension que ni le Scrum pur ni le Kanban pur ne résolvent seuls.

Un flux continu de production, c’est efficace. Mais efficace pour quoi ? Si ce qu’on produit n’est jamais évalué par le client, si personne ne se demande si la réponse apportée correspond bien au besoin, on peut très bien optimiser un flux qui fabrique de la mauvaise valeur.

C’est là qu’intervient la notion de livraison. Livrer, dans le sens agile du terme, ce n’est pas juste déployer en production. C’est remettre un résultat entre les mains de quelqu’un, et créer les conditions pour que ce résultat soit évalué et challengé.

C’est l’autre face de la visibilité. La première, interne, permet à l’équipe de se comprendre — de voir son flux, de devenir prédictible. La seconde, externe, expose le résultat à celui à qui il est destiné. La review n’est pas un rituel de validation : c’est le moment où le travail devient visible pour le client, et où sa réaction referme la boucle. Sans cette boucle, une équipe peut être parfaitement prédictible et produire, semaine après semaine, exactement la mauvaise chose.

Le client peut être satisfait. Ou son besoin peut avoir évolué depuis que la feature a été spécifiée. Ou la solution livrée résout le bon problème mais pas de la bonne façon. La livraison crée la boucle de feedback qui seule permet d’apprendre et de corriger le tir.

C’est pourquoi réduire le temps de livraison est une priorité dans les équipes les plus performantes. Pas pour aller vite. Pour apprendre vite. Le flux continu n’est pas une fin — il est au service de cette boucle.

Les idées à emporter

• L’estimation est un outil d’apprentissage, pas un engagement. Elle sert d’abord à calibrer la capacité réelle de l’équipe — pas à promettre des dates.
• La charge cognitive ne disparaît jamais. Supprimer l’estimation la déplace vers le découpage. L’effort change de forme et de moment, il ne s’évapore pas.
• Le Kanban contraint le flux, il ne fait pas que l’observer. Sans limites WIP, un board n’est qu’un tableau décoratif.
• Le throughput prédit si la distribution des tailles reste stable — pas si tous les sujets sont identiques. Le vrai danger, c’est le monstre non borné qui débarque sans prévenir.
• Le Discovery ne vit pas dans le flux de production. Mélanger l’exploration (non bornée) et la livraison (bornée) rend le système illisible.
• La prédictibilité est le but ; tout le reste est un moyen. Estimation et No Estimate sont deux chemins vers la même destination.
• Une équipe mature ne reste prédictible que si elle voit ses dérives tôt. Le CFD, le cycle time et le throughput sont des détecteurs de dérive, pas des thermomètres de confort.

Ce qu’il faut retenir

L’estimation n’est pas l’ennemi. Le No Estimate n’est pas le salut. Le CFD ne remplace pas le bon sens. Et le Kanban n’est pas une version améliorée du Scrum.

Ce sont des outils. Et comme tous les outils, leur valeur dépend entièrement de la maturité de ceux qui les utilisent — et de leur compréhension de ce que chaque outil enseigne avant d’être remplacé.

Tous tendent vers la même chose : une équipe qui voit clair sur son flux, et qui peut dire — avec une fiabilité raisonnable — ce qu’elle va livrer, et quand. La prédictibilité n’est pas un sous-produit de la méthode. C’est le but. Le reste n’est qu’un moyen d’y arriver.

Mais une équipe prédictible ne le reste que si elle voit ses dérives avant qu’elles ne s’installent. C’est peut-être là, au fond, la seule compétence qui compte vraiment : non pas atteindre l’équilibre, mais sentir le courant qui vous en éloigne.

La piscine apprend à nager. L’eau libre apprend à naviguer. L’une ne remplace pas l’autre — elle la précède.

Si cet article a résonné avec votre contexte, ou si vous traversez une de ces transitions en ce moment, les commentaires sont ouverts.