La majorité des activités de nos sociétés modernes est régie par des systèmes numériques. Les chiffres et les nombres pilotent notre quotidien et constituent le socle de la gestion de projet. Le scrum, ce cadre de travail agile aux pratiques claires, avec ses cérémonies et ses rituels, n’échappe pas à la règle. 

Lors d’une récente expérience professionnelle, une équipe Scrum a dû évoluer, s’adapter et pallier au départ de son PO. Dans ce contexte déséquilibré, certains repères habituels, notamment les story points, ne faisaient plus sens dans le processus de production. Pour autant, cette équipe a réussi à revenir à l’essentiel, redéfinir ses pratiques et travailler en co-construction directe avec les équipes métier. Cette expérience est le point de départ de cet article et a nourri cette réflexion autour de l’estimation numérique. 

Aujourd’hui, pour la majorité des équipes, le story point semble être le socle numérique pour le suivi et la maîtrise d’un projet. Mais qu’en est il de ses origines, ses liens avec le produit, ses apports mais aussi ses inconvénients… Faut-il continuer à utiliser le story point ? 

Dans le monde de l’Agilité, adaptée à l’IT, il est commun d’estimer l’effort nécessaire pour construire une fonctionnalité ou réaliser une tâche. Si l’on met volontairement de côté les estimations de type « dimensionnement », telles que les tailles de T-shirt, un système numérique comporte de nombreux avantages :

Élément numérique clé en Agile, le story point (SP) est une unité de mesure composite, couramment utilisée. Derrière cette dénomination, chère au jargon des agilistes, se cache un mix de plusieurs concepts :

Quantifier et synthétiser ces éléments en une seule valeur nous simplifie l’existence. Au-delà de faciliter un calcul de potentialité ou un ROI, évoqués précédemment, le story point permet d’évaluer relativement les fonctionnalités, les unes par rapport aux autres. L’équipe détermine la valeur en story points d’une fonctionnalité qu’elle maîtrise parfaitement, et évalue les suivantes en fonction de cette dernière. 

Soit dit en passant, cette valeur étalon importe peu et sera propre à chaque équipe, comme le reste de l’échelle de notation.

Bien que l’on puisse utiliser une échelle de valeurs via une notation sur 10 ou un pourcentage, c’est généralement la suite de Fibonacci adaptée qui est associée au story point Agile. Déclinée sous un format de carte de poker pour une utilisation facile en équipe, on la retrouve donc sous la forme suivante: 0/0.5/1/2/3/5/8/13/20/40/100…

A noter que l’utilisation de cette échelle numérique est d’ailleurs corrélable avec la durée d’une itération, d’un sprint. On constate qu’en travaillant sur des cycles courts (2 semaines), naturellement l’équipe n’utilise pas les grandes valeurs, ce qui induit et valorise le travail de découpage du product owner et la gestion fine de son backlog de produit.

Lorsqu’une équipe travaille en respectant le cadre Scrum, il est généralement admis et accepté sans condition particulière que le story point est utilisé pour estimer les éléments du backlog.

En plus de concrétiser les notions d’effort, de complexité et d’incertitude, son format numérique est également pratique en termes de gestion de projet et facilite la mise en place des indicateurs associés. Le story point devient la base du calcul de la vélocité d’équipe, sa prédictivité, sa productivité, etc. Il permet même la construction du burn up chart, assurant au product owner le suivi de l’évolution de son backlog, donc l’avancement de la construction du produit.

Finalement, en Scrum, le story point est de facto associé au backlog, à l’échelle des fonctionnalités, à l’instar de l’unité de temps qui est utilisée pour chacune des tâches opérationnelles de l’équipe.

Facilitant le story point ? Assurément…. Mais si l’on revient aux basiques, à la littérature et notamment le Scrum Guide de Ken Schwaber et Jeff Sutherland, le story point, cet élément si commun aujourd’hui, n’est pas du tout mentionné. Seule l’estimation des tâches est une pratique décrite dans le document. Ce constat pousse à la réflexion autour du lien entre l’agilité au sens d’état d’esprit, et cette gestion très chiffrée que l’on fait de Scrum aujourd’hui.

À l’échelle d’une fonctionnalité, la combinaison des complexités, durées et incertitudes est généralement difficile à déterminer pour une équipe. Bien que l’attendu ne soit pas une science exacte, ce besoin de traduire en temps et en coût au plus tôt nous amène à apporter plus d’importance aux story points donnés à chaque élément de backlog, en oubliant un peu qu’il s’agit d’une estimation complexe, mais qui est surtout relative, appuyée et confirmée par ce qui est déjà produit. 

Ce système numérique rassure ; il est concret, familier et paraît simple. L’équipe et son product owner développe une confiance excessive envers cette pratique (biais de la loi de l’instrument), le story point se substituant même à la valeur métier.

Puisqu’on attend d’elle un chiffre ou un nombre, l’équipe va naturellement se concentrer sur ce qu’elle peut quantifier, à savoir une durée et un effort à produire, reflétant la complexité. Naturellement, ce biais d’ancrage influence la prise de décision de l’équipe. L’incertitude (ou le risque), notion abstraite, se retrouve peu dans ces estimations chiffrées. C’est d’ailleurs souvent ce qui amène aux nombres les plus forts de la suite de Fibonacci (40 et 100), qui provoque ensuite une crainte quant à l’implémentation de ces éléments.

L’Agile met en avant l’empirisme, la confiance et les sentiments, or avec une telle dérive du nombre, on observe une baisse de la compréhension naturelle de l’équipe. Victime d’un biais de justification du système, elle fait le focus sur l’exactitude de son estimation, dédie une part de son énergie pour les améliorer, plutôt que de garder son attention sur le produit.

Cette perte de sens autour du produit amène l’équipe à travailler au service de ses indicateurs basés sur le story point, un résultat de vélocité devenant l’objectif principale d’une itération (biais d’actualisation hyperbolique).

Dernier point lié au management, les indicateurs de productivité, facilement calculable à partir du story point (estimation parfaitement inexacte) deviennent un levier de pression et de contrôle. Ce biais d’autorité est néfaste pour le fonctionnement d’une équipe qui subit un système de punition/récompense, plutôt que de profiter d’un climat de confiance. Dans les cas les plus grave, par la crainte du jugement du management, un biais de négativité se développe, bridant ainsi la capacité de progrès et d’innovation de l’équipe, au profit d’un résultat chiffré en fin d’itération et au dépend parfois de la satisfaction de l’utilisateur.

Cette réflexion amène naturellement la question du #NoEstimates. Il n’est pas ici question d’arrêter purement et simplement l’estimation des fonctionnalités à produire, mais plutôt de stopper un dimensionnement numérique des user stories, revenir ainsi à la priorisation métier et la valeur ajoutée du travail engagé.

Plus simple, pleine de bon sens, cette pratique ne répond plus au besoin de savoir, d’estimer, combien le développement du produit va coûter et sa durée… Mais cela n’est-il pas le propre de l’agilité ; fixer en amont budget et délai, pour se concentrer pleinement sur la priorisation pour maximiser la valeur ajoutée ?

Alors oui, pour assurer le suivi au product owner, informer le management et les sponsors, il est nécessaire de revoir les indicateurs utilisés et les construire à partir d’élément plus simple comme un simple comptage du nombre de user stories.

Avec de l’accompagnement, l’expérience et un niveau de maturité suffisant, une équipe pourra se passer du story point mais ce dernier reste rassurant pour une équipe jeune, et viendra parfaitement compléter le cadre Scrum.

En conclusion, l’utilisation du story point est une pratique répandue et particulièrement utilisée avec Scrum puisqu’elle apporte le socle chiffré nécessaire. Devenu commun, le story point semble faire partie du cadre, sauf que le scrum guide n’y fait jamais mention et ce qui apparaît comme un élément facilitant, peut rapidement devenir encombrant et limitant. L’équipe dont il était question dans l’introduction devait évoluer et s’adapter pour faire face à un contexte déséquilibré.

Pratique pour une Scrum qui se construit, relativement facile à enseigner, l’utilisation des story points est rassurante pour tout l’écosystème. Mais, accompagnée par un coach ou son manager agile, il est important qu’elle soit en capacité de challenger naturellement ses pratiques en toute confiance. Elles doivent être challengées régulièrement, adaptées, voire même délaissées, moyennant les adaptations nécessaires afin de ne pas léser les autres parties prenantes de l’écosystème de l’équipe. Ne parle-t-on pas de lever les contraintes et d’adaptation au changement lorsque l’on pratique l’agilité ?