Les estimations de petites tâches ne sont pas plus précises

Un des premiers mensonges qu’on vous livre trop souvent avec SCRUM c’est qu’on peut estimer des petites tâches avec bien plus de précision que des grandes, et qu’en conséquence on peut être assez fiable dans l’estimation des une à trois semaines de chaque itération.

Foutaises !

Combien de temps faut-il pour mettre les blousons avant d’aller à l’école ? Mettons 30 secondes si on ne se presse pas. La réalité c’est que ça mettra plus souvent 5 minutes que 30 secondes, et ça c’est si on n’a pas besoin de se battre.

400% de marge d’erreur ? Comment voulez-vous faire un planning avec de telles estimations. Pourtant on est sur une tâche connue, répétée chaque jour. Seule solution, on triche et on compte 2 minutes 30. Même ainsi on a une marge d’erreur de 100%. Hallucinant !

Ce n’est pas un exemple choisi. J’ai le même problème pour terminer la tartine, pour boire le verre d’eau ou pour passer aux toilettes avant de partir, pour descendre dans la rue, pour faire le trajet, pour trouver le badge et passer le portail de l’école, pour montrer ma carte au vigile, pour les 10 mètres dans l’école au milieu des copains et autres parents d’élèves, pour le bisou de bonne journée avant de pouvoir repartir…

Ce n’est pas non plus la faute d’une mauvaise analogie. Estimer une petite tâche est juste impossible parce que le moindre aléa fait tout exploser.

Ajouter un lien sur une page ça prend 30 secondes… sauf si on vous dit de changer l’URL au dernier moment et qu’il faut faire deux fois le travail, sauf si c’est le seul lien à cet endroit et qu’il faut retoucher les règles de style, sauf si le lien passe à la ligne en plein milieu et que visuellement ça ne le fait pas du tout sur ce composant, sauf si l’espace pris fait glisser le bouton qui suit sous le clavier sur un smartphone une fois le clavier déplié, sauf s’il faut partir à la chasse de la bonne URL parce que c’était « ça n’a pas d’impact, on donnera le lien au dernier moment », sauf si on se rend compte qu’il faut mutualiser ce lien avec autre chose ailleurs dans l’application, sauf si ajouter un lien casse le test end-to-end et qu’il faut le réécrire pour faire passer le serveur d’intégration continue au vert, sauf si… pour un simple foutu lien !


Et pourtant, on n’est jamais en retard à l’école. Malgré les aléas infinis à chaque tâche, le projet « aller à l’école » prend 45 minutes à ±15 minutes. Pas plus.

Ce n’est même pas qu’estimer le projet dans son ensemble permet de lisser les risques de dérapages, c’est que le temps que prend chaque tâche dépend de toutes les tâches précédentes et des options qu’il nous reste pour les suivantes.

S’il faut lutter pour terminer le croissant alors on active sérieusement la suite. Si les toilettes s’éternisent je prépare le blouson et le bonnet pendant ce temps. S’il le faut on presse un peu le pas. À l’école, si on arrive dans les derniers, aucun parent d’élève ou camarade ne nous retient dans les dix derniers mètres et le bisou sera vite fait. Si vraiment on est super en retard on peut toujours sortir le vélo ou prendre le tram.


En réalité si SCRUM estime les fonctionnalités unitaires ce n’est pas pour s’engager sur un résultat donné à l’avance, ni même pour mesurer si l’itération a été une réussite ou un succès lors de la rétrospective. C’est uniquement pour savoir où on va dans la boîte de temps qu’on s’est donnée. Rien de plus.

Quand on vous dit que ça permet d’être plus fiable, derrière se cache l’hydre du « on va transformer vos estimations en engagement » voire du « on va ajouter vos estimations une à une et ça donnera la deadline de fin de projet si rien ne change ».

Rejoindre la conversation

2 commentaires

  1. Sur le fond, je suis bien d’accord, des estimations ne doivent pas devenir des engagements : ça ne marche jamais !

    Sur la forme, j’ai quelques remarques. D’abord, ce que l’on nous vend avec Scrum, ce n’est pas que chaque estimation sur une petite tâche est précise, c’est juste que si on a suffisamment d’estimations, les erreurs vont statistiquement avoir moins d’importance. On peut avoir 400% d’erreur sur une tâche, si elle est noyée dans un lot de 20 tâches de tailles plus ou moins égales, ça ne va pas faire une grosse différence sur le total. C’est le même principe que pour les mutuelles : elles assurent un grand nombre de personnes et même si une personne va à l’hôpital et coûte très cher à rembourser, sur le nombre de personnes, ça s’équilibre bien.

    Bref, on n’achète pas un mensonge évident (les estimations sur les petites tâches sont précises) mais une affirmation qui est plus facile à faire passer : si on découpe un gros projet en petites tâches, la somme des estimations pour les petites tâches sera plus précise que juste une estimation du gros projet. À titre personnel, je ne suis pas convaincu de cela, j’ai pu par le passé faire une première estimation d’un projet, puis la retravailler en découpant le projet en tâches, et l’estimation initiale au doigt mouillé était parfois meilleure que l’estimation plus détaillée (mais pas tout le temps). Je serais curieux de savoir s’il y a des études scientifiques sur ce sujet. C’est fort possible que cette affirmation soit vraie. Ceci dit, même si elle est vraie, les estimations restent trop imprécises pour devenir des engagements.

    1. Découper en plus petites tâches permet aussi de voir mieux le moment où on prend du retard et donc de reporter dès ce moment là l’ESTIMATION de la fin du développement. Et de ne pas arriver à la fin de la durée estimée de la grosse tâche et de ne réorganiser le développement qu’à ce moment là … ( quand on a des contraintes de temps )

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par OVH SAS, joignable par téléphone au +33 (0)9 72 10 10 07 et dont le siège social est au 2 rue Kellermann, 59100 Roubaix, France.