Story Point(less)

S’il existe bien un mythe persistant dans #Scrum c’est la nécessité d’estimer les Product Backlog Items (PBI) en story points. Oui, cette fameuse suite de Fibonacci revisitée.

Allons tout de suite droit au but - bien que je sois plus Phil Collins que Van Halen - rien, absolument rien, dans le Scrum Guide n’oblige à estimer les PBIs, et encore moins avec des story points.

Pourtant je dirais qu’au doigt mouillé plus de 90% des équipes qui débutent en Scrum les utilisent et sans forcément savoir pourquoi, par mimétisme la plupart du temps, comme si cela faisait partie du starter kit.

Rappelons que le Scrum Guide n’est qu’un framework léger, court de seulement 13 pages. Il décrit ce qui doit être fait mais pas comment le faire. Chaque équipe peut choisir les outils ou méthodes complémentaires qui lui conviennent le mieux, en toute liberté. C’est cette liberté, que l’on pourrait appeler également autonomie, qui fait la force de Scrum.

Faire passer les story points et le poker planning pour un package de base de Scrum est une grave erreur. Et ce pour plusieurs raisons.

La première, c’est qu’en incluant automatiquement cette pratique, l’équipe va l’appliquer sans se poser la question de sa pertinence ou de son utilité.

La seconde est que la confusion est souvent faite entre complexité et temps estimé. Si j’avais voulu bosser en jours homme, j’aurais fait du cycle en V.

Ce qui nous mène à la troisième raison. Le management pourrait être tenté de demander un rapport de vélocité à chaque fin de sprint pour voir s’il en a pour son argent et que l’équipe performe toujours. Pire, il pourrait même être tenté de comparer deux équipes entre elles, ce qui soyons clairs, n’a absolument aucun sens. De plus, si une équipe se faisait challenger sur sa vélocité, elle n’aurait qu’à gonfler artificiellement ses estimations pour qu’on la laisse tranquille. Malheureusement, cette situation est rencontrée bien trop souvent.

Enfin, en ne se focalisant que sur la vélocité, on perd de vue l’essence même de Scrum : délivrer de la valeur au client. Quel intérêt de livrer 25, 50 ou bien même 100 story points par sprint si aucune fonctionnalité n’apporte quoique ce soit au client ? On retrouve ici les vieilles habitudes où tout ce qui comptait était de livrer toutes les fonctionnalités du cahier des charges. Et non de savoir si elles avaient une utilité ou apportaient de la valeur au produit. On livre des points, on est contents.

Vous me direz “C’est bien gentil tout ça mais moi je fais comment sans story points ?”.

Déjà, il est possible d’estimer autrement, notamment en taille de t-shirts. Vu qu’on n’utilise pas des nombres, on peut être moins tenté de trouver une équivalence entre complexité et temps estimé. A vous de voir ensuite combien de S, M, L etc. vous pensez pouvoir embarquer dans un sprint.

Ensuite, on peut ne pas estimer du tout. Cette technique appelée “no estimate” part du principe que toute estimation est par nature fausse. Pourquoi perdre du temps à produire un résultat faux ? Ne pas estimer ne veut pas dire embarquer n’importe quelle quantité de PBIs à chaque sprint planning. S’intéresser au flux de son process et calculer son throughput permet de savoir combien de PBIs sortent par sprint, et ainsi de savoir quelle quantité de travail embarquer lors du sprint planning. Se baser sur son historique de données pour prendre une décision est bien plus pertinent que sur des estimations.

A titre personnel, je ne regarde pas pas la vélocité de mon équipe et je ne la connais pas. Pourquoi ? Tout simplement parce qu’elle ne m’apporte aucune information utile. En revanche, je sais combien d’user stories (US) l’équipe est capable de sortir à 30 jours avec 85% de probabilité (simulation Monte Carlo). Je connais également le temps qu’une US met à sortir du système une fois qu’elle y est entrée (Cycle Time), toujours avec une probabilité de 85%. Tout ce qui m’intéresse ensuite c’est de savoir si l’US qui va être embarquée peut être terminée dans ce délai. Si on pense que non, l’US doit être redécoupée. Gain de temps, prévisions améliorées, que de demander de plus ?

Je n’essaie pas de vous faire mettre les story points à la poubelle, mais plutôt de vous amener à vous poser la question de leur utilité dans votre contexte. Le poker planning peut être une bonne façon d’ouvrir une discussion entre les développeurs sur leur façon d’aborder d’une US. Mais n’existe-t-il pas d’autres façons de la déclencher ? La vélocité dans les premiers sprints peut être utile pour avoir une idée de quoi embarquer sur le prochain sprint. Mais ne peut-on pas avoir quelque chose de plus précis ? (spoiler : oui, cf plus haut).

Pour ceux dont j’aurais réussi à éveiller la curiosité, je vous invite à vous intéresser aux travaux de Daniel Vacanti sur le sujet. Il est l’auteur notamment de deux livres références sur le sujet : “Actionable Agile Metrics for Predictability” et “When Will It Be Done ?”.

Pour terminer, je me suis retenu de parler d’US quasiment jusqu’au bout car comme pour les story points, cela n’est pas obligatoire dans Scrum, mais ça sera peut-être pour une prochaine fois. Un mythe à la fois et c’est déjà pas mal…

#agile #scrum #scrumguide #storypoints #noestimate #flow #fibonacci