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™ : Une étude de cas sur la surcharge des processus

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.

Le rituel d'estimation : les points de récit en action

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.

Le débat autour des points de récit

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.

Plaidoyer pour les points de récit (Mike Cohn)

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

Plaidoyer contre les points de récit (Ron Jeffries)

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.

Autres voix dans le débat

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.

La réalité : avantages et inconvénients

Avantages

• Favorise la collaboration d'équipe : selon GBH Tech, elle encourage les discussions entre les membres de l'équipe afin de parvenir à un consensus quant à la complexité des tâches, ce qui conduit à une compréhension partagée.
• Facilite l'estimation relative : Scrum.org indique que cette méthode permet aux équipes d'évaluer les tâches en fonction de leur complexité et de l'effort qu'elles requièrent par rapport aux autres tâches, plutôt qu'en fonction du temps absolu.
• Découple l'estimation du temps* : Cela aide les équipes à se concentrer sur l'effort et la complexité des tâches sans la pression des estimations basées sur le temps, qui peuvent varier d'une personne à l'autre.

*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.

Inconvénients

• Incohérence entre les équipes : Stack Exchange indique que les points d’effort sont subjectifs et peuvent varier d’une équipe à l’autre, ce qui rend difficile la comparaison des performances et des progrès au sein d’une organisation.
• Risque d’utilisation abusive : Selon Uplevel Team, les organisations peuvent utiliser à mauvais escient les points d’effort comme mesure de la performance individuelle, ce qui peut entraîner une concurrence malsaine et du stress au sein des équipes.
• Fausse impression de prévisibilité : Selon Blue Yonder, le recours aux points de récit pour la planification à long terme peut créer une illusion de prévisibilité, qui risque de ne pas tenir compte des complexités ou des changements imprévus.

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.

Amélioration du backlog et son importance

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.

Pourquoi «BacklogRefinement» plutôt que «Grooming»?

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 ».

Ce que BacklogRefinement apporte réellement

• Compréhension partagée plus fine : les responsables produit, les développeurs, les testeurs et les concepteurs examinent chaque élément ensemble, révélant les dépendances cachées et faisant apparaître les critères d’acceptation manquants avant le début du travail.
• Réduction précoce des risques : les ambiguïtés et les obstacles sont mis en évidence bien avant la planification du sprint, évitant ainsi les surprises de dernière minute susceptibles de faire dérailler les engagements.
• Adaptation des efforts : les équipes décomposent les éléments volumineux ou vagues en tranches plus petites et testables, puis les réévaluent, ce qui permet de maintenir le backlog exploitable et prêt pour le prochain sprint.
• Priorisation juste-à-temps : le raffinement offre un point de contrôle régulier pour confirmer que les éléments correspondent toujours aux objectifs du produit et aux besoins des parties prenantes, de sorte que les efforts sont toujours consacrés aux tâches à plus forte valeur ajoutée.
• Une planification de sprint plus saine : un backlog bien affiné permet de se concentrer sur la capacité et l’engagement plutôt que sur les clarifications d’urgence, ce qui raccourcit la réunion et améliore la précision des prévisions.

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.

Conseils pratiques

• Préparation asynchrone. Le responsable produit ajoute le contexte initial (description, valeur, critères d'acceptation) à l'avance ; les membres de l'équipe laissent leurs questions ou leurs résultats directement sur le ticket.
• Utilisez la définition de « prêt » comme une liste de contrôle. Ne déplacez pas un élément vers « prêt pour le sprint » tant que tout le monde n’a pas convenu qu’il répond aux critères (énoncé de valeur, notes de test, suffisamment petit pour être terminé dans un sprint, etc.).
• Faites tourner l'animation. Laissez différents membres de l'équipe animer la session pour maintenir un niveau d'énergie élevé et partager la responsabilité de la qualité du backlog.
  

Comment favoriser des discussions de perfectionnement plus efficaces

• Veillez à ce que l'affinage du backlog soit axé sur la complexité, et non uniquement sur les chiffres.
• Encouragez les exercices comparatifs pour faciliter la décomposition des éléments complexes.
• Si une tâche semble trop incertaine, considérez-la comme une exploration plutôt que de forcer une estimation.
• Veillez à ce que le perfectionnement débouche sur des actions concrètes : des exigences clarifiées, des tâches plus petites ou des plans techniques précis.

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.

Estimation vs. dimensionnement

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 estimations visent à prédire le temps calendaire, ce qui les rend intrinsèquement subjectives.
• Le dimensionnement classe les éléments selon l'effort relatif ou l'incertitude, ce qui facilite la répartition de la charge de travail.
• Attention au piège de la « totalisation » : comme les points d’effort sont numériques, les équipes les additionnent parfois à la fin d’un sprint et jugent le succès en fonction de l’atteinte (ou de l’absence) d’un objectif de points – par exemple : « nous n’avons livré que 48 points ; ce n’est pas suffisant ». Cela transforme l’estimation de la taille en un indicateur de vélocité et réintroduit la pression du calendrier.
• Des échelles alternatives permettent de rompre avec cette habitude. Les tailles de t-shirts (S, M, L, XL) ou les étiquettes de Fibonacci sans chiffres explicites découragent l'addition et recentrent la conversation sur la complexité relative plutôt que sur des quotas.

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.

Mesures alternatives aux points d'effort

Au lieu des points d'effort, les équipes peuvent adopter des indicateurs alternatifs :

• Tailles de t-shirts (S, M, L, XL) : Une méthode de dimensionnement plus simple, basée sur les catégories.
• Système de fourre-tout : catégorisation du travail en groupes discrets selon leur taille.
• Catégorisation basée sur les risques : Attribution des efforts en fonction de l’incertitude et des obstacles potentiels.
• Estimation basée sur les données historiques : Utilisation des tendances passées pour prédire l’effort avec plus de précision.

« 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. »

- Story points changes in agile iterative development

Débit : mesurer le travail effectué

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.

Indicateurs DORA : une meilleure mesure de l’efficacité

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 :

• Fréquence de déploiement : fréquence à laquelle une équipe publie du code avec succès.
• Délai de mise en œuvre des modifications : le temps écoulé entre une validation et le déploiement en production.
• Taux d'échec des modifications : le pourcentage de déploiements qui aboutissent à un échec.
• Temps moyen de rétablissement (MTTR) : durée nécessaire pour rétablir le service après un incident.

Comment agir en fonction des chiffres

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. »

- Agile Scrum Sprint Velocity DataSet

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.

Faire des compromis dans les organisations rigides

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.

Conclusion : aller au-delà des points de récit

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 :

• Le dimensionnement plutôt que l’estimation pour une meilleure répartition de la charge de travail.
• Le débit et les métriques DORA pour suivre les performances réelles.
• Réduire le temps consacré aux estimations au profit de techniques de planification plus efficaces.

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.

Critiques supplémentaires

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.