Les points d'effort (story points) sont une méthode d'estimation couramment utilisée dans le développement Agile. Ils permettent de mesurer l'effort relatif nécessaire à la réalisation d'une tâche. Au lieu d'estimer le travail en heures absolues, les équipes évaluent la complexité, l'incertitude et la portée. Cette approche vise à améliorer la prévision et la répartition de la charge de travail.
Un point d'effort est une unité de mesure qui représente l'effort perçu nécessaire pour réaliser une user story ou une tâche. Contrairement aux estimations basées sur le temps, les points d'effort tiennent compte de divers facteurs tels que la complexité, les dépendances et les risques, permettant ainsi aux équipes de comparer les tâches de manière relative plutôt qu'en heures ou en jours précis.
Dans le secteur actuel, les points d'effort demeurent un outil fondamental, bien que controversé. S'ils permettent aux équipes d'évaluer l'effort sans s'engager dans des estimations de temps strictes, de nombreuses organisations peinent à les mettre en œuvre. Un mauvais usage des points d'effort peut engendrer des débats excessifs, une précision artificielle, voire une perte de productivité. Avec l'adoption croissante des méthodes agiles dans tous les secteurs, il devient crucial d'évaluer si les points d'effort apportent une réelle valeur ajoutée ou s'ils ne font qu'alourdir les procédures administratives.
D'après le Guide Scrum, les points d'effort permettent aux équipes d'évaluer l'effort de manière relative plutôt qu'absolue. Cela leur permet de comparer les tâches entre elles plutôt que d'essayer de prédire leur durée exacte. Pour illustrer cela concrètement, prenons l'exemple d'un cas d'utilisation malheureusement courant. Cet exemple est tiré d'une histoire vraie.
Bureaucrasoft™ est un fournisseur de solutions logicielles d'entreprise de premier plan, spécialisé dans l'optimisation des flux de travail, la gestion de la conformité… et garantissant qu'aucune décision ne sera prise en moins de six semaines.
Le produit phare, ProcessPal™, est une plateforme de bureaucratie en tant que service (BaaS) de bout en bout conçue pour aider les organisations à « optimiser » (lire : ralentir) leurs opérations grâce à des listes de contrôle obligatoires, des contrôles d'autorisation automatisés et des revues d'alignement interfonctionnelles.
Chez Bureaucrasoft™, l'estimation des points d'effort n'est pas qu'une simple réunion : c'est un rituel. Chaque lundi matin, l'équipe de développement se réunit dans la grande salle de conférence, munie d'un café et d'une bonne dose de résignation. Le Product Owner, suivant scrupuleusement le guide des bonnes pratiques d'estimation de Bureaucrasoft (173 pages), lance la séance.
« Très bien, commençons par le premier point : la refonte de la barre de navigation dans ProcessPal™. Qu'en pensez-vous ? »
Le développeur principal du frontend soupire. « La navigation actuelle est un véritable fouillis de code hérité. Si on touche à un seul élément, tout risque de s'effondrer. C'est un travail colossal. »
« Mais nous n’avons pas le temps de tout réécrire », rétorque le Product Owner. « Nous pouvons simplement apporter quelques petites améliorations. Peut-être un huitième ? »
Une demi-heure plus tard, après avoir examiné les estimations précédentes, débattu des facteurs de risque et consulté l’équipe de conformité de Bureaucrasoft, ils se mettent d’accord sur huit points de récit.
Dernière étape : la mise en place d’un système de thèmes personnalisés. Un silence s’installe. Chacun sait que la tâche est ardue : les utilisateurs réclament des thèmes personnalisables depuis des mois. Cela implique des modifications de l’interface utilisateur, des API côté serveur et des optimisations de performance. L’ingénieur en chef soupire : « C’est au moins un treizième défi. »
« Et si on simplifiait les exigences ? » demande le Scrum Master. « Peut-être huit ? »
Le débat se poursuit. Finalement, treize points d'effort sont attribués et la réunion prend fin trois heures plus tard. Épuisée, l'équipe se disperse, sachant que la semaine prochaine, elle devra se disputer sur les raisons pour lesquelles sa vélocité n'atteint pas celle du sprint précédent.
Comme dans notre exemple, il arrive que les équipes consacrent plus de temps à l'estimation qu'à la réalisation de la tâche elle-même, ce qui entraîne des inefficacités. Certains experts en méthodes agiles ont abordé ce problème, soulignant que les efforts excessifs consacrés à l'estimation l'emportent souvent sur les bénéfices.
Les points d'effort restent l'un des concepts les plus controversés du développement Agile. Certains estiment qu'ils améliorent la collaboration au sein des équipes et la précision des estimations, tandis que d'autres affirment qu'ils introduisent une complexité inutile et peuvent être mal utilisés par la direction. Pour illustrer ces deux points de vue, nous examinerons deux figures influentes du monde Agile : Mike Cohn, partisan des points d'effort, et Ron Jeffries, sceptique.
Mike Cohn, cofondateur de la Scrum Alliance, affirme que les points de récit aident les équipes à se concentrer sur l'effort et la complexité plutôt que sur les délais, ce qui favorise de meilleures discussions et une meilleure compréhension.
« Les points d'effort sont une unité de mesure permettant d'estimer l'effort global nécessaire à la mise en œuvre complète d'un élément du backlog produit. » – Mike Cohn
Ron Jeffries, co-créateur de la programmation extrême (XP), regrette d'avoir introduit les points de récit, arguant qu'ils créent une précision artificielle et qu'ils sont mal utilisés par la direction.
« J’aime à dire que j’ai peut-être inventé les points de récit, et si c’est le cas, je m’en excuse aujourd’hui. » – Ron Jeffries
D'autres critiques, comme Allen Holub et Joshua Kerievsky, affirment que les points de récit introduisent une complexité inutile, tandis que des partisans comme Andrea Fryrear et Dave West y voient une valeur ajoutée en termes de visualisation et d'avantages pédagogiques.
Outre Cohn et Jeffries, d'autres figures de proue de l'agilité se sont penchées sur la question. Allen Holub critique vivement les points d'effort, arguant qu'ils entraînent des lourdeurs administratives inutiles. Joshua Kerievsky, PDG d'Industrial Logic, suggère que les points d'effort introduisent une complexité superflue, évitable grâce à une approche de livraison continue. À l'inverse, Andrea Fryrear, experte en marketing agile, souligne que les points d'effort peuvent aider les équipes à mieux visualiser leur charge de travail. Dave West, PDG de Scrum.org, reconnaît également la valeur pédagogique des points d'effort, affirmant qu'ils incitent les équipes à analyser la complexité des tâches de manière critique.
*Les points de récit sont souvent confondus à tort avec les heures ou les jours. Les équipes doivent insister sur leur nature relative afin d'éviter cette erreur fréquente.
Les points d'effort, comme tout outil Agile, ne sont efficaces que s'ils sont bien mis en œuvre. Utilisés à bon escient, ils permettent de guider le développement sans microgestion. Mal utilisés, ils peuvent se transformer en un véritable cauchemar bureaucratique qui ralentit les équipes. L'essentiel est de comprendre quand et comment les utiliser efficacement.
L'affinage du backlog est un processus continu de révision, de mise à jour et de priorisation des éléments du backlog produit afin de garantir leur clarté, leur définition précise et leur aptitude à être mis en œuvre. Il aide les équipes à gérer la dette technique, à identifier les dépendances et à affiner les critères d'acceptation, ce qui permet un développement plus fluide et une meilleure exécution des sprints.
Le terme « gestion du backlog » a été largement abandonné par le secteur en raison de ses connotations négatives. On lui préfère désormais « affinage du backlog », qui met l’accent sur la clarification et l’amélioration continues des éléments de travail plutôt que sur leur simple « rangement ».
Un bon travail de perfectionnement est rapide et efficace. La plupart des équipes expérimentées limitent la durée de la réunion à 30 à 45 minutes par semaine, soit 5 à 10 % de la capacité totale du sprint. Si la réunion déborde régulièrement, cela indique que les éléments du backlog sont trop vagues à leur arrivée ou que l'animation doit être optimisée.
Une séance de raffinement bien menée ne se contente pas de produire des estimations ; elle rend le travail plus prévisible et réalisable. Lorsque les équipes comprennent l’étendue de leur travail, la planification est plus fluide et l’exécution s’en trouve améliorée.
Les points d'effort sont souvent considérés comme des estimations, mais ils constituent en réalité un outil d'évaluation relative. Au lieu de prévoir le temps d'exécution, les équipes devraient se concentrer sur la catégorisation des tâches en fonction de leur complexité.
Les grandes organisations peuvent toujours avoir besoin de prévisions pour la planification à long terme, mais le fait de passer des conversations quotidiennes des équipes de l'estimation au dimensionnement favorise une prestation plus saine et fondée sur des données probantes.
Le guide Scrum 2020 souligne ce changement, en mettant l'accent sur le dimensionnement et en abandonnant les références à l'estimation basée sur le temps.
Au lieu des points d'effort, les équipes peuvent adopter des indicateurs alternatifs :
« Des travaux empiriques récents portant sur plus de 19 000 tickets Jira ont révélé qu’un élément du backlog sur dix nécessitait une augmentation de 58 à 100 % du nombre de points d’effort après la planification du sprint, ce qui compromettait directement les prévisions que ces points étaient censés étayer. »
Le débit correspond au nombre de tâches accomplies sur une période donnée. Il donne un aperçu des taux de livraison de l'équipe, mais ne constitue pas un indicateur d'efficacité, car il ne tient pas compte de la complexité des tâches ni des facteurs externes. Il convient donc d'utiliser le débit conjointement à d'autres indicateurs pour obtenir une vision complète de la productivité de l'équipe.
Des outils comme Axify permettent de suivre le débit et l'efficacité des flux de travail.
Pour une vision plus complète de l'efficacité, les équipes peuvent s'appuyer sur les indicateurs DORA (DevOps Research and Assessment). Ces indicateurs portent sur la performance et la fiabilité de la livraison des logiciels :
Un délai de livraison élevé ? C’est souvent le signe que les user stories sont surdimensionnées ou mal découpées. Raffiner et découper le travail en incréments plus petits et testables (voir notre guide sur le découpage des user stories SPIDR) réduit la complexité, raccourcit le temps de revue de code et de déploiement, et donc diminue le délai de livraison. Cette pratique stabilise également la taille des user stories en points : les éléments plus petits sont plus faciles à dimensionner.
Les indicateurs DORA offrent aux équipes des méthodes empiriques pour évaluer leur efficacité, favorisant ainsi l'amélioration continue. Des outils comme Axify proposent ces indicateurs prêts à l'emploi.
« Les ensembles de données publics sur la vélocité (par exemple, Spring XD, Mesos) montrent une corrélation beaucoup plus forte entre le débit d'articles simple et le délai de livraison qu'entre le total des points de récit et le délai de livraison. »
Nathen Harvey, qui dirige l'équipe DORA chez Google Cloud, souligne l'importance des indicateurs DORA pour comprendre et améliorer les performances de la livraison de logiciels :
Cela souligne l'importance de ces indicateurs pour évaluer et améliorer l'efficacité des processus de développement.
Certaines entreprises résistent au changement et restent ancrées dans des processus fondés sur des estimations. Or, cette rigidité est souvent le véritable problème. Parmi les compromis possibles :
Chez Bureaucrasoft™, toute modification du processus d'estimation est soumise à une procédure d'approbation en plusieurs étapes. Un développeur senior, exaspéré par les interminables débats autour des estimations, élabore un plan.
Au lieu de proposer un changement radical d'emblée, il commence par de petites expérimentations. Pour les corrections de bugs mineurs et les ajustements rapides de l'interface utilisateur, son équipe ignore complètement les points d'effort et se contente de terminer le travail. Pour les fonctionnalités les plus importantes, ils remplacent l'estimation détaillée par points par un système de tailles simplifié : petit, moyen, grand et très grand. Le processus est rationalisé, mais les chiffres restent suffisamment vagues pour éviter un examen immédiat par la direction.
L'expérience est concluante. Les tâches progressent plus rapidement et les réunions de raffinement du backlog sont plus courtes. Cependant, le véritable défi réside dans le leadership, qui demeure obstinément attaché au suivi de la vélocité.
Pour les convaincre, l'équipe suit discrètement le débit (le nombre de tâches terminées par sprint) et le compare aux estimations précédentes basées sur les points d'effort. Les résultats sont sans appel : le travail est réalisé plus rapidement et les délais de cycle s'améliorent. Ils présentent ces résultats dans un rapport structuré, démontrant une augmentation de la productivité de 15 % depuis la réduction des coûts liés aux estimations.
Après des semaines de persuasion étayée par des données, la direction accepte une approche hybride : les fonctionnalités à fort impact continuent d’être comptabilisées en points d’effort, tandis que les tâches mineures sont traitées sans discussion. Progressivement, de plus en plus d’équipes adoptent cette approche et Bureaucrasoft™ amorce une transition vers un flux de travail plus agile et axé sur les résultats.
La leçon à retenir ? Le changement au sein des organisations rigides ne se fait pas du jour au lendemain. En démontrant leur efficacité par de petites victoires, les équipes peuvent inciter leur entreprise à adopter des méthodes de travail plus performantes et efficaces.
Les points d'effort peuvent convenir à certaines équipes, mais ne constituent pas une solution idéale. L'essentiel est de retenir que la planification et les discussions sont plus importantes que les estimations arbitraires. Les équipes devraient se concentrer sur :
La meilleure approche dépend du contexte et des contraintes de l'équipe, mais une transition vers une planification empirique et fondée sur les données améliorera les résultats de la mise en œuvre à long terme.
Joshua Kerievsky’s Critique : Le PDG d'Industrial Logic affirme que les points de récit peuvent introduire une complexité inutile :
« Les calculs de points d'effort et de vélocité sont des techniques artificielles qui perturbent inutilement les équipes au début de leur parcours agile. »
Alternative Metrics Discussion : In a discussion on alternative metrics, a practitioner suggests focusing on predictability scales estimated by those completing the tasks, rather than traditional story point planning:
« La gestion de projet moderne (y compris les méthodes agiles) accorde une importance excessive à l'homogénéité des données et à la recherche d'une objectivité maximale. Mon idée est de privilégier une approche plus subjective, où le degré de prévisibilité est estimé par les personnes qui réaliseront la tâche, plutôt que par une planification collective. »
Brightball’s Analysis : Un article de Brightball critique la fiabilité des points de récit et suggère qu'ils pourraient ne pas mesurer efficacement la performance de l'équipe :
« Les points de récit sont totalement peu fiables, source de confusion et nécessitent de rappeler constamment à toutes les personnes impliquées ce qu'ils sont et ce qu'ils ne sont pas. »
“Story Points are Pointless, Measure Queues” by Brightball : Cet article soutient que l'utilisation des points d'effort peut engendrer de la confusion, des incertitudes quant aux délais et de la démotivation au sein des équipes. Il suggère qu'il serait plus efficace de mesurer les files d'attente et de se concentrer sur l'efficacité des flux de travail.
“Story Point Estimation Doesn’t Work. Here’s Why » par Uplevel : Uplevel aborde la variabilité et les biais inhérents à l'estimation par points d'effort, en soulignant que les équipes attribuent souvent ces points de manière incohérente. L'article met en évidence l'incapacité des points d'effort à prendre en compte le travail non planifié et suggère qu'ils peuvent s'avérer inefficaces pour la gestion du temps en entreprise.
“Why Story Points Don’t Work” by Alejandro Wainzinger : Cet article critique la précision de l'estimation de la complexité à l'aide de points de récit, arguant que de telles estimations sont intrinsèquement erronées et ne devraient pas constituer un objectif principal.
“Agile Effort Estimation: Have We Solved the Problem Yet? Insights From A Replication Study” : Cette étude universitaire examine l'efficacité des modèles d'apprentissage profond pour l'estimation agile des efforts et suggère que les méthodes actuelles, y compris les points de récit, peuvent ne pas fournir d'estimations précises.