Solliciter l’équipe pour une estimation de l’effort est faisable bien sûr, mais il ne sert à rien de chercher à chiffrer à l’euro près. Pour que ça ait du sens il faudrait aussi pouvoir estimer la valeur produite à l’euro près, et on sait tous qu’une telle affirmation relèverait de la prestidigitation (que ça soit pour l’effort ou la valeur).
Normalement, l’estimation de la valeur devrait être suffisante pour ordonner les items du backlog produit les plus prioritaires. On n’a pas vraiment besoin d’ordonner en permanence tout le backlog produit, ce qui est important c’est de savoir dire avec certitude quels sont les 3/4 premiers et dans quel ordre. Le PO a aussi le droit d’être incohérent avec les chiffres, et d’avoir des items qu’il préfère à d’autre pour des raisons qualitatives plutôt que quantitatives (par exemple pour privilégier l’image de marque ou la sécurité au chiffre d’affaire).
Si vraiment on a un doute et qu’on a vraiment 2 fonctionnalités au coude-à-coude qu’on ne sait pas trop ordonner, on peut effectivement essayer de les départager par niveau de complexité. Dans ce cas, il suffit de faire une estimation T-shirt sizing, voire même juste de demander à l’équipe laquelle semble moins compliquée à implémenter. Il n’y a pas de raison de faire ce travail de manière systématique.
Il est important de se rappeler que Scrum est conçu la base pour faire des fonctionnalités complexes et empiriques. On va donc se limiter à travailler sur une seule fonctionnalité pendant le sprint, pour laquelle on va faire un incrément utilisable qui sera plus ou moins un « prototype ». Ensuite on collecte du feedback utilisateur pour décider de ce qu’on fait après. On n’a donc pas besoin de savoir précisément si le plan initial nous prendra plutôt 68,5 ou 73,1 JH. De toutes façons, on va travailler un sprint dessus et il y a de fortes chances que l’implémentation soit très différente de ce qu’on avait imaginé au départ.
Pour paraphraser le général Von Molke, à la guerre, la première victime, c’est le plan.
Le focus sur l’estimation de l’effort de dev est une truc classique qu’on voit dans les équipes qui font du bourrage de sprint avec plein de petites stories. L’autre symptôme c’est le travail très parallélisé : chacun sa tâche et peu de coordination. Normalement en Scrum, toute l’équipe travaille ensemble pour faire marcher une grosse fonctionnalité complexe, qui nécessite les compétences de tous. C’est une mêlée, pas un parcours de golf.
Si chaque PBI est nettement plus petit que l’effort de toute l’équipe pendant un sprint, il faut essayer de voir à réduire l’équipe (si y’a pas trop de problème de compétences), ou réduire la durée du sprint (si y’a pas disproportion du processus de DOD). Ca peut aussi être que les PBI sont décrits trop fins, voire trop « spécifiés ». Et si vraiment l’équipe manipule plein de petits sujets indépendants, peut-être que Scrum n’est pas la meilleure méthode de travail.
