Story Point Estimation Using Large Language Models

Cette étude démontre que les grands modèles de langage peuvent estimer les points de complexité des tâches logicielles avec une précision supérieure aux modèles d'apprentissage profond traditionnels, et ce, sans données d'entraînement ou avec très peu d'exemples, tout en montrant que l'utilisation de jugements comparatifs comme exemples peu nombreux améliore encore ces performances.

L'essentiel

Imaginez que vous dirigez une équipe de construction. Avant de commencer à bâtir une maison, vous devez estimer combien de temps et d'effort cela va prendre. Dans le monde du développement logiciel, on utilise une unité de mesure un peu mystérieuse appelée « points d'histoire » (story points). Ce n'est pas une heure ni un jour, mais une estimation relative de la difficulté d'une tâche.

Traditionnellement, les développeurs se réunissent pour jouer à un jeu appelé « Poker de Planification » pour décider de ces points. C'est long, subjectif et ça demande beaucoup d'énergie mentale.

Cette étude cherche à répondre à une question simple : Peut-on demander à une intelligence artificielle très avancée (un « Grand Modèle de Langage » ou LLM) de faire ce travail à notre place ?

Voici l'explication de leurs découvertes, imagée comme une aventure de cuisine et de comparaison.

1. Le Défi : L'IA peut-elle cuisiner sans recette ? (Zero-Shot)

Imaginez que vous donnez à un chef étoilé (l'IA) une liste d'ingrédients (la description d'une tâche logicielle) et que vous lui demandez : « Combien de temps va prendre la cuisson ? » sans lui donner aucune recette ni aucun exemple de votre cuisine spécifique.

• L'expérience : Les chercheurs ont demandé à quatre chefs IA (DeepSeek, Kimi, Gemini, OpenAI) de deviner les points d'histoire sur 16 projets différents, sans aucun entraînement préalable.
• Le résultat : C'est incroyable ! Même sans avoir jamais vu vos projets, ces chefs IA ont deviné mieux que des systèmes traditionnels qui avaient lu 80% de vos recettes passées.
• La métaphore : C'est comme si un chef qui n'a jamais visité votre maison pouvait deviner, juste en regardant vos ingrédients, que faire un gâteau au chocolat prendra plus de temps que de faire une salade, et même estimer à quel point il sera plus long. L'IA a une « intuition » générale très forte.

2. L'Amélioration : Donner quelques exemples (Few-Shot)

Même si l'IA est douée, elle ne connaît pas vos goûts spécifiques. Que se passe-t-il si vous lui donnez cinq exemples de tâches précédentes avec leurs temps de cuisson exacts ?

• L'expérience : On donne à l'IA cinq petites cartes avec des exemples de tâches et leurs points.
• Le résultat : La précision s'améliore considérablement.
• L'astuce de la sélection : Il y a deux façons de choisir ces cinq exemples :
  1. La méthode « Fréquence » : Choisir les 5 tâches les plus courantes (ex: 5 petites salades).
  2. La méthode « Échelle » (Gagnante) : Choisir une tâche très facile, une très difficile, et trois dans le milieu.
• La leçon : La méthode « Échelle » fonctionne mieux. C'est comme si vous disiez au chef : « Voici comment on fait une salade, voici comment on fait un banquet, et voici des plats intermédiaires ». Cela aide l'IA à comprendre l'échelle de votre cuisine, pas juste la moyenne.

3. Le Grand Mythe : Comparer est-il plus facile ?

Il existe une théorie humaine selon laquelle il est plus facile de dire « Le plat A demande plus d'effort que le plat B » (comparaison) que de dire « Le plat A demande 5 heures » (chiffre exact). C'est plus intuitif pour les humains.

• L'expérience : Les chercheurs ont demandé à l'IA de faire exactement cela : comparer deux tâches et dire laquelle est plus difficile.
• Le résultat surprenant : Non, ce n'est pas plus facile pour l'IA.
• La métaphore : Pour un humain, comparer deux photos est facile. Pour l'IA, elle semble avoir besoin de « calculer » un chiffre interne pour faire la comparaison. Quand on lui demande de comparer directement, elle fait plus d'erreurs que quand on lui demande de donner un chiffre. L'IA pense différemment des humains : elle a besoin de nombres, même si elle ne les dit pas toujours.

4. L'Alternative : Utiliser les comparaisons comme « étiquettes »

Même si l'IA n'est pas meilleure pour prédire une comparaison, peut-on utiliser des comparaisons (faites par des humains) pour entraîner l'IA ?

• L'expérience : On donne à l'IA des exemples du type : « Tâche A > Tâche B » (A est plus dur que B) et on lui demande de deviner les points d'histoire.
• Le résultat : Cela fonctionne très bien ! Pour certains modèles d'IA plus « légers » (comme Gemini), utiliser des comparaisons humaines est même meilleur que de leur donner des chiffres exacts.
• La métaphore : C'est comme si vous ne pouviez pas donner de recette précise à un apprenti, mais vous pouviez lui dire : « Ce gâteau est plus dur que celui-là ». Pour certains apprentis (les petits modèles), cette information relative est plus précieuse que des chiffres abstraits.

En résumé : Ce que cela change pour vous

1. Pas besoin de données : Vous pouvez utiliser l'IA pour estimer vos projets logiciels dès le premier jour, même sans historique. Elle est déjà assez intelligente pour faire un bon travail.
2. Un peu d'aide suffit : Donner seulement 5 exemples bien choisis (du plus petit au plus grand) rend l'IA très précise.
3. L'IA n'est pas humaine : Ne comptez pas sur elle pour faire des comparaisons simples comme le ferait un humain. Elle préfère les chiffres, même si elle doit les inventer.
4. L'avenir de l'estimation : Les équipes peuvent maintenant utiliser l'IA pour gagner du temps. Si vous avez un modèle d'IA puissant, donnez-lui des exemples chiffrés. Si vous avez un modèle plus petit ou limité, donnez-lui des comparaisons simples (« ceci est plus dur que cela ») et il s'adaptera parfaitement.

C'est une nouvelle façon de travailler où l'IA agit comme un assistant très rapide qui comprend le contexte, réduisant la fatigue mentale des équipes de développement.

Résumé technique

Voici un résumé technique détaillé de l'article de recherche intitulé "Story Point Estimation Using Large Language Models", rédigé en français.

1. Problématique

L'estimation des efforts dans le développement logiciel agile, et plus particulièrement l'attribution de points d'histoire (story points), est une tâche cruciale pour la planification des sprints et l'allocation des ressources. Cependant, ce processus repose traditionnellement sur des techniques collaboratives subjectives (comme le Planning Poker), qui sont chronophages, difficiles à mettre à l'échelle et coûteuses.

Les approches d'apprentissage automatique (ML) existantes, basées sur des réseaux de neurones profonds, ont montré des résultats prometteurs mais souffrent d'une limitation fondamentale : elles nécessitent de grandes quantités de données étiquetées (points d'histoire annotés par des humains) provenant du même projet pour être efficaces. Cela les rend peu pratiques pour les nouveaux projets (scénarios "cold-start") ou les projets aux données limitées.

Cette étude se pose la question de savoir si les Modèles de Langage de Grande Taille (LLM) peuvent surmonter ces limites en estimant les points d'histoire sans données d'entraînement (zero-shot) ou avec très peu d'exemples (few-shot), et si l'utilisation de jugements comparatifs (comparer deux tâches pour savoir laquelle est plus difficile) est une méthode d'annotation plus efficace pour ces modèles.

2. Méthodologie

Les auteurs ont mené une étude empirique systématique sur 16 projets logiciels réels (données issues de JIRA, titres et descriptions des éléments de backlog). Ils ont évalué quatre LLMs différents :

• DeepSeek-V3.2 (DeepSeek)
• Kimi (Moonshot K2)
• Gemini Flash Lite (Google)
• OpenAI GPT-5 Nano

L'évaluation a été structurée autour de quatre questions de recherche (RQ) :

• RQ1 (Zero-shot) : Les LLMs peuvent-ils prédire les points d'histoire sans aucune donnée d'entraînement ?
  • Approche : Utilisation d'un prompt direct demandant l'estimation basée uniquement sur le titre et la description.
• RQ2 (Few-shot avec étiquettes) : L'ajout de quelques exemples étiquetés améliore-t-il la performance ?
  • Approche : Comparaison de deux stratégies de sélection d'exemples :
    • Count-based : Sélection basée sur la fréquence des valeurs de points.
    • Scale-aware : Sélection visant à couvrir toute l'étendue des points (du minimum au maximum).
• RQ3 (Comparaison directe) : Est-il plus facile pour les LLMs de prédire des jugements comparatifs (A > B) que des valeurs absolues ?
  • Approche : Comparaison de la précision des jugements pairs directs vs la précision dérivée des estimations de points absolus.
• RQ4 (Few-shot avec jugements comparatifs) : Les jugements comparatifs peuvent-ils servir d'exemples few-shot pour améliorer l'estimation des points absolus ?
  • Approche : Utilisation de paires d'items avec leur relation comparative (A > B) comme contexte few-shot pour prédire les points d'un nouvel item.

Métriques d'évaluation :

• Coefficient de corrélation de Pearson ($\rho$) pour l'alignement linéaire.
• Coefficient de corrélation de rang de Spearman ($r_s$) pour l'alignement de l'ordre relatif.
• Précision (Accuracy) pour les jugements comparatifs.

3. Contributions Clés et Résultats

A. Performance Zero-Shot (RQ1)

• Résultat : Les LLMs, sans aucun entraînement, surpassent les modèles d'apprentissage supervisé de pointe (entraînés sur 80 % des données) en termes de corrélation de rang ($r_s$) et souvent de corrélation linéaire ($\rho$).
• Détails : Les modèles Kimi et DeepSeek ont obtenu les meilleurs résultats (moyenne $\rho \approx 0.40$ et $r_s \approx 0.41$), surpassant les modèles de régression basés sur SBERT. Cela démontre que les LLMs possèdent des connaissances transférables sur la complexité logicielle.

B. Impact du Few-Shot (RQ2)

• Résultat : L'ajout de seulement 5 exemples améliore significativement les performances pour tous les modèles.
• Stratégie : La stratégie "Scale-aware" (couvrir l'étendue complète des points d'histoire) s'est révélée supérieure à la stratégie basée sur la fréquence (Count-based). Cela indique que fournir des ancres de calibration sur toute l'échelle est plus efficace que de simplement montrer les valeurs les plus courantes.

C. Jugements Comparatifs vs Estimation Absolue (RQ3)

• Résultat Inattendu : Contrairement aux études humaines où la comparaison est plus facile, il n'est pas plus facile pour les LLMs de prédire des jugements comparatifs directs que des points d'histoire absolus.
• Analyse : La précision des jugements comparatifs directs est inférieure à la précision des jugements dérivés des estimations de points absolus. Cela suggère que les LLMs s'appuient sur une représentation numérique latente interne, même lorsqu'ils sont interrogés sur des comparaisons, et que le format comparatif explicite n'est pas optimal pour leur architecture.

D. Jugements Comparatifs comme Signal d'Entraînement (RQ4)

• Résultat : Bien que la prédiction directe des comparaisons soit moins précise, utiliser des jugements comparatifs comme exemples few-shot améliore les performances d'estimation des points absolus par rapport au zero-shot.
• Nuance importante : Pour les modèles plus légers ou contraints (comme Gemini Flash Lite), les jugements comparatifs en few-shot ont même surpassé les exemples étiquetés directs. Pour les modèles plus puissants (DeepSeek, Kimi), les exemples directs restent légèrement supérieurs, mais les comparaisons restent une alternative viable et moins coûteuse en annotation.

4. Signification et Implications Pratiques

1. Alternative Faible Coût : L'utilisation de LLMs permet une estimation des efforts de haute qualité sans nécessiter de vastes bases de données historiques étiquetées, résolvant le problème du "cold-start".
2. Réduction de la Charge Cognitive : Bien que les jugements comparatifs ne soient pas intrinsèquement plus faciles à prédire pour les IA, ils sont plus faciles à obtenir des humains (moins de charge cognitive). Ils peuvent donc servir de signal d'entraînement efficace, en particulier pour des modèles plus petits ou dans des contextes où l'annotation numérique est difficile.
3. Calibration de l'Échelle : Les LLMs sont naturellement meilleurs pour capturer l'ordre relatif (Spearman) que la magnitude absolue exacte (Pearson). L'utilisation d'exemples few-shot diversifiés est cruciale pour calibrer le modèle sur l'échelle spécifique d'un projet.
4. Hétérogénéité des Modèles : Il n'existe pas de solution unique. Les modèles avancés bénéficient de labels directs, tandis que les modèles plus légers peuvent tirer un meilleur parti des signaux relatifs (comparatifs).

Conclusion

Cette étude démontre que l'application des LLMs à l'estimation des points d'histoire est une approche prometteuse et viable. Elle offre une alternative peu coûteuse aux méthodes d'apprentissage supervisé traditionnelles, capable de fonctionner avec zéro ou très peu de données étiquetées. L'intégration de jugements comparatifs comme mécanisme de calibration few-shot ouvre de nouvelles voies pour des flux de travail agiles hybrides, combinant l'intuition humaine (facile à exprimer par comparaison) et la scalabilité des modèles foundation.