Les story points ne servent à rien, mesurez les files d’attente

• Les story points sont totalement peu fiables, génèrent de la confusion et obligent à rappeler sans cesse leur signification aux parties prenantes
  • Les faibles valeurs en points sont plus précises, mais les valeurs élevées supposent une plus forte variabilité, représentent une plage et ne peuvent pas être additionnées avec précision
  • Les story points ne représentent pas le temps, mais une fois combinés à la métrique de vélocité, ils finissent de facto par désigner du temps, ce qui contredit dès le départ l’idée d’additionner des nombres et des plages
• L’estimation logicielle est difficile, et le résultat produit par le processus est généralement peu utile par rapport à l’effort fourni
• Les petites équipes avec peu d’interruptions donnent l’impression d’estimer correctement, ce qui laisse penser dans la plupart des cas que leur façon de travailler fonctionne bien
• Quand la capacité est totalement utilisée, la variabilité de tout le travail explose, ce qui affecte brutalement toutes les estimations et tous les calendriers
• Mesurer les files d’attente permet de résoudre les problèmes d’estimation à court et à long terme, de gérer naturellement les changements de périmètre et d’offrir un exercice bien plus utile aux grandes équipes tout en éliminant l’incertitude
• Les files d’attente mesurées fournissent un indicateur avancé capable de prédire les problèmes 20 fois plus vite que les métriques liées à la vélocité ou au cycle time

Que sont les story points ?

• Selon Atlassian, les story points sont une unité qui exprime une estimation de l’effort total nécessaire pour implémenter complètement un élément du backlog produit ou un autre travail
• Les points représentent la complexité, la charge de travail, le risque ou l’incertitude, ainsi que la quantité de travail
• La mesure de la complexité est une notion relative, et différentes équipes peuvent évaluer différemment une même tâche
• En raison de la nature relative des points, les comparaisons entre équipes n’ont aucun sens, ce qui pose souvent problème au niveau du management

Variabilité intrinsèque

• Les story points sont basés sur la suite de Fibonacci, ce qui signifie que plus la valeur est élevée, plus la variabilité qu’elle représente est grande
• Additionner des valeurs de points fortement variables n’a aucun sens, et le fait de sommer les points dans une métrique de vélocité est une erreur
• Selon la loi de Goodhart, dès qu’une mesure devient un objectif, elle cesse d’être une bonne mesure

Problèmes connus

• Les problèmes des story points sont bien connus, mais comme les techniques d’estimation alternatives souffrent de difficultés similaires, ils sont toujours utilisés
• Ron Jeffries, créateur des story points, les rejette et critique leur mauvais usage
• Dans Scrum, le terme "Commitment" a été remplacé par "Forecast", mais l’usage reste malgré tout erroné
• Il existe une situation paradoxale où faire plus de travail que prévu peut au contraire valoir des reproches

Prioriser par le ROI

• Les entreprises priorisent le travail afin d’optimiser les ressources (temps, argent, outils, personnes)
• Les estimations de développement sont nécessaires pour calculer le coût d’investissement, mais l’estimation elle-même est difficile et coûteuse
• Software Estimation: Demystifying the Black Art est un excellent livre qui traite de la difficulté de l’estimation

Le résultat du processus

• Le processus d’estimation en story points consomme beaucoup de temps, mais le résultat produit n’a pas de valeur
• Les sessions régulières de refinement prennent beaucoup de temps et sont appliquées de façon très variable, sans cohérence entre équipes
• Il est plus utile de produire une liste de travail significative que d’utiliser des story points

Propositions alternatives

• Estimer en tailles de T-shirt peut être une meilleure alternative, mais cela présente aussi des limites
• Estimer en temps pose des problèmes similaires, car le temps de travail réel de l’équipe diffère du temps attendu par le métier
• Dans les petites équipes, l’estimation en temps peut bien fonctionner, mais à mesure que l’équipe grandit, sa précision diminue
• Le livre de Donald Reinertsen, "The Principles of Product Development Flow", propose une alternative
  • L’idée clé est d’optimiser le flux de travail en se concentrant sur la gestion des files d’attente (Queue)
  • Il faut planifier la capacité et prévoir une capacité tampon capable d’absorber la variabilité

Solution

• Le point de départ consiste à ce que l’équipe analyse ensemble le travail, le découpe en petites tâches et élimine les incertitudes
• La liste des tâches devient une file d’attente (Queue), et le nombre total de tâches représente la taille du travail (Job Size)
• À la place des story points, on utilise le taux moyen d’achèvement des tâches (Average Task Rate) pour estimer
• Le travail est suivi sur la base de la vitesse moyenne d’exécution des tâches, et le taux d’achèvement est calculé
• Lorsque les tâches sont mises à jour selon de nouvelles informations ou de nouveaux retours, l’estimation s’ajuste naturellement
• Les développeurs n’ont plus à subir de pression psychologique liée à l’estimation

La file d’attente (Queue) est un indicateur avancé

• Le taux moyen d’achèvement des tâches, le cycle time, la vélocité, etc. sont des indicateurs retardés, tandis que la Queue est un indicateur avancé
• Quand la taille de la Queue augmente, il devient possible de détecter les problèmes à l’avance et d’y répondre

Résumé

• Les story points créent de la confusion, ne sont pas fiables et sont voués à l’échec par conception
• À la place, il est pertinent et utile de consacrer du temps à ce que l’équipe comprenne ensemble le problème, élimine les incertitudes, découpe le travail en tâches et gère la Queue

Avis de GN+

• La méthode de gestion de file d’attente présentée dans l’article semble être une alternative réaliste pour surmonter les difficultés d’estimation dans le développement agile
• Cependant, le découpage des tâches en éléments fins peut demander des efforts supplémentaires aux développeurs, et les phases initiales du projet peuvent prendre plus de temps
• En outre, le processus d’analyse des tâches suppose une participation active des développeurs et l’expression honnête de leurs avis
• D’un autre côté, on peut aussi en attendre un effet positif : aider l’équipe de développement à mieux comprendre les exigences métier et à y réfléchir collectivement

[heal9179]

N'est-ce pas justement la méthodologie Kanban.. ?

[GN⁺]

Avis Hacker News

• D’après mon expérience personnelle, le chiffre des story points n’avait pas d’importance, mais le processus par lequel l’équipe évalue la complexité du travail était très utile

  • Utiliser les story points pour estimer le temps de travail n’était pas un indicateur fiable
  • J’essaie d’éviter les story points pour plusieurs raisons, notamment les changements d’équipe et de domaine, ainsi que la variabilité des tâches hors développement
  • Dans les équipes qui utilisaient les story points, ils servaient d’outil pour partager la compréhension du travail

• Dans le guide Scrum, le passage de « Commitment » à « Forecast » ne date pas de 2011

  • Après vérification des guides 2010 et 2011, le mot « Commitment » n’apparaissait pas dans les versions antérieures à 2011
  • « Forecast » a remplacé « Estimate » dans le guide 2020

• Décomposer les lots de travail en unités atomiques et mesurer la longueur de la file d’attente relève d’un autre ordre de problème

  • On peut utiliser les story points en affinant les lots de travail avec l’équipe
  • Décomposer tout le travail en tâches de 1 story point s’est révélé inefficace
  • Faire le lien entre la longueur de la file d’attente et l’impact de la variabilité est un concept intéressant

• L’approche waterfall et l’estimation en unités de temps peuvent aussi bien fonctionner dans certains cas

  • Dans une petite équipe de services spécialisés, les exigences du client étaient documentées puis discutées avec l’équipe avant d’être estimées sous forme de fourchette horaire
  • Une fois l’approbation du client obtenue, on passait par les étapes de conception détaillée, développement, QA et mise en production
  • Le processus n’a pas changé depuis 20 ans et l’équipe est considérée comme très productive

• Les story points représentent une complexité relative et de l’incertitude, pas une unité de temps

  • Il faut pouvoir mesurer une story avec de grands nombres
  • Certaines équipes n’attribuent pas plus de 7 points
  • Ailleurs, on voyait aussi des estimations à 21, 30 ou 50 points

• Les story points étaient en pratique une unité de temps approximative

  • Faire correspondre clairement les story points à une unité de temps est trompeur
  • Il est important de prévoir combien de temps un développeur consacrera à une tâche
  • Pour que l’analyse de file d’attente soit utile, il faut connaître le temps estimé de chaque tâche

• Lors de mes débuts avec Scrum, nous utilisions Rally

  • Nous suivions à la fois les story points, le temps estimé et le temps réel
  • Après le passage à Jira, le suivi du temps a disparu
  • À mesure que les estimations devenaient plus précises, il est devenu plus facile d’équilibrer la charge de travail de l’équipe

• Les story points sont utiles pour discuter de la complexité du travail, mais inadaptés pour mesurer la vélocité

  • En tant que nouvel ingénieur, je traitais beaucoup de story points, mais la direction essayait de les ajuster
  • Il était difficile d’évaluer correctement les tâches complexes

• Estimer de manière fiable les projets de développement logiciel est difficile

  • Il est important de découper le travail en petites unités avec l’équipe et d’estimer des fourchettes de temps
  • À mesure que le projet avance, il est important de rendre compte de la liste des fonctionnalités et des nouvelles fourchettes d’estimation

• Estimer en unités de temps est une meilleure méthode

  • Les story points finissent de toute façon par être convertis en temps
  • Il est plus efficace d’éviter les procédures complexes de Scrum et d’achever le travail