Nouvelle Perspective sur les Story Points

• “Je veux arrêter d’utiliser les story points.”
• “Quoi ?”
• “C’est une blague, non ?”
• “Mais, pouvons-nous vraiment faire ça ?”
• “Mais cela ne va-t-il pas complètement à l’encontre de Scrum ?”
• “C’est vraiment la dernière chose que je m’attendais à entendre de la part d’un Scrum Master !”

Voilà une conversation que j’ai eue récemment avec mon équipe. J’avais passé des mois à leur montrer à quoi servent les story points : vélocité, affinement, prévisions sur un sprint, mais en vain. Ils n’étaient tout simplement pas intéressés.

L’Abandon des Story Points

J’ai donc estimé qu’il était enfin temps d’arrêter de perdre du temps et de se débarrasser complètement des story points. Pourquoi passer du temps sur quelque chose que vous n’utilisez pas ?

L’équipe était sous le choc. Ils ne pouvaient pas imaginer faire du Scrum sans story points. Je suppose qu’ils craignaient aussi qu’un manager vienne leur faire des reproches.

J’ai donc proposé que nous le fassions à titre expérimental : l’essayer pour un Sprint et ensuite se reposer cette question si nécessaire. Mais bien sûr, à la fin du Sprint, tout le monde avait oublié les story points et c’était la fin de l’histoire.

Les Story Points

Au cas où vous ne seriez pas familier avec les story points, je vous recommande de consulter cet article de Maarten Dalmijn. Sa description correspond parfaitement à ma vision des choses :

En termes simples, les story points sont une technique pour faire une estimation relative de l’effort nécessaire pour livrer un élément de travail donné, ou comme nous le disons en Scrum, un élément du Backlog Produit (PBI). En d’autres termes, les story points sont un outil avec un objectif très spécifique. Efficace si vous l’utilisez correctement. Un triste gaspillage de temps sinon.

Une incompréhension de ce fait simple a conduit à beaucoup de négativité envers les story points. Une simple recherche illustre cela : https://medium.com/search?q=story+point. C’est assez malheureux car comme je l’ai dit, si utilisés correctement, les story points peuvent être un outil précieux.

La Valeur des Story Points

Pour moi, les story points sont un moyen très efficace d’apprendre à préparer le travail en le décomposant en morceaux gérables. C’est une compétence inestimable pour les développeurs. C’est le moyen le plus efficace d’obtenir une compréhension claire du travail. Comme le souligne Maarten Dalmijn dans son article, plus un élément de travail est petit, plus le niveau d’incertitude est faible.

Cette compétence a diverses conséquences. Par exemple, elle facilite la planification d’un Sprint, car l’équipe peut estimer plus précisément la quantité de travail qu’elle peut gérer. Cela est important car cela soutient le flux de travail. Fini le stress à la fin du Sprint pour tout terminer !

Cela aide même avec, oserais-je le dire, la planification. Aussi tentant que soit de croire que nous pouvons tous simplement nous plonger dans le travail avec les mots “ce sera fait quand ce sera fait”, ce n’est tout simplement pas réaliste. Même d’un point de vue Agile, il est pratique de pouvoir au moins avoir une idée de ce qui peut être fait quand. Si quelque chose prend des années à construire, même s’il s’agit d’une estimation très approximative, vous y réfléchirez certainement différemment que quelque chose qui prend des jours à livrer.

L’important à accepter ici est que les estimations ne donnent qu’une idée très approximative. J’aime bien dire que nous tentons le globalement juste plus que le précisément faux. Dans ce sens, l’estimation n’est pas un outil de planification, mais un outil de priorisation. C’est une distinction importante. C’est la différence entre un diagramme de Gantt où tout est question de délais et de leur respect, et une feuille de route qui montre dans quel ordre les choses seront livrées. Cela conduit à deux conversations complètement différentes :

“Si cette chose va prendre quelques mois, alors commençons par cette autre chose d’abord, car nous n’avons besoin de la première chose que dans un an ou plus et il y aura suffisamment de marge pour la réaliser à temps.”

au lieu de :

“La date limite pour cette chose est dans 61 jours, mais les progrès indiquent que nous ne pourrons pas respecter la date limite de 22 jours pour pouvoir commencer cette autre chose, donc nous devons commencer à penser aux heures supplémentaires.”

Enfin et surtout, apprendre à préparer leur travail permet à une équipe de collaborer plus facilement. Travailler ensemble sur un seul PBI est un défi, souvent limité à la programmation en binôme, quelque chose à quoi il y a souvent une certaine aversion et qui n’est pas nécessairement efficace. Diviser un PBI en parties plus petites permet à plusieurs développeurs de travailler sur les différentes parties en parallèle, favorisant la concentration et forçant l’alignement continu entre les développeurs. Voilà : un chemin vers une collaboration efficace !

Les Story Points comme Outil d’Apprentissage

Alors, comment les story points aident-ils à apprendre à préparer votre travail ? Eh bien, ils nous donnent un moyen simple de visualiser la taille d’un élément de travail, fournissant la boucle de rétroaction parfaite pour apprendre à décomposer le travail.

Mais, comment est-ce possible, vous pourriez vous demander, considérant que les story points sont relatifs et que personne n’a aucune idée de comment ils se traduisent en temps absolu ? Eh bien, c’est en fait assez facile. Une équipe s’engage à livrer un certain nombre de story points pendant un Sprint. Si elle n’y parvient pas, alors ses estimations étaient trop optimistes. Si elle y parvient et a du temps en plus, alors ses estimations étaient trop conservatrices. Faites cela quelques Sprints et l’équipe commencera automatiquement à développer une sensation pour ce qu’est un story point.

Mais à mon avis, c’est en fait encore plus facile que ça. À la fin d’un Sprint, et surtout s’ils n’ont pas atteint leur engagement, une équipe pointera automatiquement le PBI qui a pris plus de temps que prévu. C’est une question de fierté, le désir naturel d’un développeur d’exceller dans son travail.

Et oui, c’est une intuition, et c’est parfaitement bien. L’essentiel est que c’est l’erreur, et non la précision, qui compte. Plus une équipe est mauvaise en estimation, plus grande sera la marge par laquelle elle ne respectera pas son engagement, et donc plus l’apprentissage sera efficace.

Si vous vous inquiétez de la gravité pour une équipe de manquer à son engagement, réalisez que c’est une façon de penser axée sur les résultats. Le succès du Sprint est déterminé par un résultat : atteindre l’objectif du Sprint, et non une quantité de travail spécifique. Se concentrer sur l’objectif rend automatiquement la portée flexible, donnant à l’équipe beaucoup de marge pour apprendre cette compétence utile.

Les Story Points ne sont pas une question de justesse, mais d’apprentissage. Et c’est génial parce que cela signifie que nous n’avons pas besoin de prendre tout cela trop au sérieux ! Qui se soucie de savoir si c’est un 3 ou un 5 ? Des discussions sans fin pour parvenir à un consensus ? La vraie conversation a lieu après, quand nous parlons de savoir si nous avons atteint notre engagement ou non.

Sachant que l’apprentissage se fait le mieux lorsque nous le gamifions, cela devient soudainement une opportunité. Moi-même, je ne fais plus jamais de sessions de poker, je fais de l’estimation avec de l’extrem quotation. Ce jeu est simple : mettez en place une table avec la séquence de Fibonacci dans la ligne de titre, et demandez à l’équipe de déplacer individuellement les PBIs vers la colonne qu’ils pensent être juste. Dites quelque chose de stupide comme “celui qui déplace le plus d’éléments gagne un prix” pour bien montrer que c’est un jeu. Assurez-vous simplement que les gens s’amusent. Si vous avez une équipe qui s’inquiète de la fiabilité des estimations, dites-leur qu’ils pourront discuter des estimations avec lesquelles ils ne sont pas d’accord après le jeu.

Ce que vous obtiendrez, c’est une estimation éclair où tout le monde participe. J’ai eu des équipes qui estimaient 40 éléments en 10 à 20 minutes. Et cela inclut les discussions après.

Conclusion

Voilà donc la vraie valeur des Story Points. Un outil simple qui repose sur l’intuition et l’instinct de votre équipe. Juste sur cette base et la boucle de rétroaction que le Sprint fournit, les équipes apprennent progressivement à décomposer leurs histoires en moins de 5 story points chacune.

Et une fois que vous arrivez à ce point – 1, 2 ou 3 story points – l’apprentissage est terminé et vous pouvez vous débarrasser des story points et de l’engagement. Vous voyez, vous avez résolu la seule hypothèse de la loi de Little qui rend son utilisation avec Scrum si difficile, à savoir que tous les PBIs devraient avoir des tailles similaires. Félicitations, vous pouvez maintenant commencer à utiliser les métriques Kanban pour faire tout ce travail d’estimation : Cycle Times, Lead Times et Service Level Expectations (SLEs).

Mais attendez, ça devient encore mieux que ça. La beauté est que cette nouvelle compétence que les développeurs ont apprise signifie non seulement qu’ils peuvent décomposer le travail de manière fiable, mais aussi qu’ils seront capables d’estimer n’importe quoi pour vous !

J’ai eu des équipes où le Product Owner demandait simplement combien de temps prendrait une certaine fonctionnalité, voire un projet entier, et l’équipe donnait tout aussi simplement une estimation en Sprints. La clé est une règle simple sur laquelle nous devons tous nous mettre d’accord :

“Plus l’élément à estimer est grand, plus la marge d’erreur est grande”

Le résultat est que ces équipes ne font plus de ‘raffinements classiques’, elles font des sessions de brainstorming dans lesquelles elles décomposent le travail et vous donnent ensuite une estimation encore meilleure.

Qui l’aurait cru, les Story Points sont un outil utile et amusant, que vous pouvez mieux mettre en place comme un jeu, et qui est motivé par la propre motivation de l’équipe à ‘gagner’ : que ce soit pour atteindre leur engagement, leur objectif de Sprint, ou tout ce qui titille leur ego.

Et imaginez juste ce moment où vous dites à votre équipe :

“Félicitations les gars, vous n’avez plus besoin de Story Points, d’Engagement ou de Vélocité. Vous êtes tellement cool que vous faites ce que beaucoup de gens pensent être impossible !”