Récemment un ami m'expliquait qu'il avait été surpris d'une remarque d'un PO. Ce dernier était fier que l’équipe ai sorti 82% des points engagés car ça n'était encore jamais arrivé (d'ordinaire ça moyenne à 55% de l'engagement). Sa première remarque a été que l'équipe technique ne sait probablement pas faire d'estimations. Rien ne l'exclu pour le moment, mais c'est un réflexe que j'ai déjà vu/entendu, et qui, je trouve, nous empêche de voir plus loin que la responsabilité des devs. Sans pouvoir rencontrer le PO de suite, on s'est donc pris au jeu des hypothèses et des zones à explorer, et plutôt que de mettre un wall of text, j'ai pondu mes idées dans un doc que je restitue quasi tel quel ici, modulo des détails qui complexifieraient la compréhension. La forme sera donc celle que j'emploie par chat d'ordinaire.
Au sujet des mauvaises estimations je pense que c’est questionnable : si la moyenne de 55% n’a pas un écart-type de malade (genre 20 points?) alors le réalisé est plutôt stable, ce qui signifie nécessairement que l’estimation de l’équipe rend le périmètre réalisé en fin d’itération prédictible : 55% de l’engagement. Et je pense qu’on en demande pas plus que d’être prédictible à des estimations. Si les estimations sont mauvaises, donc avec un écart-type de ouf, ça veut certes dire qu’il y a quelque chose à faire côté dev, mais ce serait surprenant de la part d’une équipe qui existe depuis un moment, et probablement aussi que le PO a un problème de découpe de ses tickets (plus c’est fin, plus c’est simple à estimer, plus c’est gros, plus c’est faux, il saboterait donc sa capacité à prédire)
En supposant des estimation "justes", pour moi la toute première question serait : si cela fait un moment qu’ils font en moyenne 55% de ce qu’ils estiment, est-ce parce qu’à chaque sprint après avoir révisé la capacité de l’équipe ils font 55% de moins que la nouvelle estimation (donc en gros c’est méchamment dégressif et donc grave), ou est-ce parce qu’ils ne prennent pas en compte la capacité de l’équipe mais l’estimation d’un backlog qui ne bouge pas par rapport à une cible qui ne bouge probablement pas (auquel cas faire des prédictions sur ce qu’ils auront est plutôt compliqué d’une part, mais d’autres part ça veut dire qu’il n’y a pas révision des solutions (peut-être même pas de brainstorming avec les métiers pour savoir comment atteindre une date avec un périmètre fonctionnel soutenable et acceptable ?))
Pourquoi c’est intéressant : si le PO est fier que l’équipe ai pu faire 82% je prend l’hypothèse que c’est parce que la capacité de l’équipe était de 55% de ce qui est habituellement estimé, et donc que la capacité de l’équipe n’est pas révisée. Hypothèse corollaire : le PO compte plus sur un effort redoublé de l’équipe de dev pour sortir des tickets à la date malgré son retard, plutôt que sur un dialogue avec les devs et le métier pour atteindre la date avec des fonctionnalités acceptables pour le client et soutenable pour l’équipe.
En se projetant sur les différents cas : Si la capacité d’équipe n’est pas révisée, peut être que le périmètre ne l’est pas.
Si l’écart de 82% est aussi notable, c’est une exception, et pour moi ça devrait être autant scruté/investigué qu’un incident car hors norme. Quels changements dans les pratiques ? La nature des tickets ? Il y a peut être des choses à en tirer pour reproduire le résultat, ou peut être que c’est impossible, mais la question c’est qu’est-ce qui a changé dans le processus, est-ce un trou ? (quelque chose de pas fait / ignoré) une amélioration ? Autre chose ? Exemple qui parait débile mais c’est du déjà vu, on se met à compter les bugs, ou tout autre type de ticket qui n’a rien à voir avec nos engagements avec le client et qu’on ne comptait pas jusque là
Avec les 55% t’as aussi évoqué gestion du temps. Ça peut vouloir dire comme tu le soulignais qu’ils le gèrent mal, donc par exemple qu’ils ne timeboxent pas ou mal leurs expérimentations (test d’implem d’une story sur laquelle ils se sont engagés) et c’est curieux dans ce cas s’ils arrivent à reproduire régulièrement 55% avec un problème aussi variable, mais là va falloir leur parler pour savoir. C’est aussi possible qu’ils passent effectivement le temps estimé sur leurs tickets, mais qu’ils ne font pas tous leurs tickets car d’autres tâches que celles planifiées leur mange leur capacité. En gros faut partir à la chasse du travail non planifié, et la première que je regarderai dans ce cas ce sont les bugs, les incidents, le support (en ont-ils ?), et de voir les métriques qui correspondent (quel Mean Time to Restore, quel Change Failure Rate, voire quel Lead Time aussi, quelle tendance de nombre de tickets de bug, nombre d’occurence d’incident (et faux positifs)). Et selon ce qui est observé là y’a tellement de possibilités que je ne vais pas tenter différentes hypothèses, faudra qu’on reparle.
Plusieurs hypothèses qui ne concernaient pas les devs étaient pas loin d'être vraies, et posent pas mal de questions sur la maintenabilité de ce projet et la soutenabilité des efforts sur le long terme. Mais la dure vérité sur cette performance exceptionnelle, est que l'équipe a changé la durée de son sprint. Donc pour le même "volume" de tâches que d'ordinaire et en plus de temps, l'équipe a atteint 82% de son engagement. Elle n'a simplement pas pris en compte le changement de référentiel.
