Les agents IA dans vos sprints : comment les copilotes changent la signification d'un story point

Développeur travaillant avec un assistant de codage IA, un écran montrant du code en cours de génération tandis que l'autre affiche un tableau de sprint avec des estimations en story points, illustrant la tension entre la vitesse de l'IA et l'estimation traditionnelle Un ingénieur backend de votre équipe prend une story de 5 points. Historiquement, c'est une journée et demie de travail. Avec Cursor et Claude, il la livre en une heure. Au sprint suivant, l'équipe examine un ticket similaire et quelqu'un demande : "Est-ce toujours un 5 ?" Personne n'a de bonne réponse. Cela se produit actuellement dans des équipes partout, et la plupart du contenu agile n'a pas encore rattrapé son retard.

Le problème n'est pas l'inflation de la vélocité

La réaction évidente est "super, nous sommes plus rapides maintenant". Mais le problème est plus profond que des chiffres de vélocité plus élevés. Les story points sont censés mesurer la complexité relative. Un 5 devrait représenter à peu près la même quantité d'effort, peu importe qui le prend. L'IA brise cette hypothèse de deux manières : L'accélération est inégale. Un développeur junior utilisant Copilot pourrait voir une amélioration de vitesse de 3x sur un endpoint CRUD routinier. Un développeur senior travaillant sur une intégration complexe avec des API peu familières pourrait ne voir aucune amélioration, ou même ralentir. L'étude METR de mi-2025 a révélé que les développeurs open-source expérimentés étaient 19 % plus lents avec l'assistance IA sur des tâches réelles, tout en croyant être 20 % plus rapides. La même personne est plus rapide sur certaines tâches mais pas sur d'autres. Les agents IA gèrent bien le code répétitif et les patterns bien documentés. Ils ont du mal avec les décisions architecturales et tout ce qui nécessite un contexte approfondi sur votre base de code spécifique. Un développeur pourrait terminer trois stories de 3 points en une matinée, puis passer deux jours sur une seule story de 5 points où l'IA n'a cessé de générer des solutions plausibles mais incorrectes. Cela rend l'estimation extrêmement incohérente. Votre graphique de vélocité commence à ressembler à un sismographe.

Ce que les équipes vivent réellement

Parlez aux responsables techniques qui gèrent des sprints avec des équipes augmentées par l'IA et vous entendrez les mêmes schémas : Des chiffres de vélocité qui ne signifient rien. Une équipe a rapporté être passée d'une moyenne stable de 45-60 points par sprint à 55-65, mais le travail accompli ne semblait pas proportionnellement différent. Un codage plus rapide ne se traduisait pas par une livraison plus rapide car les délais de revue de code, de QA et de déploiement restaient les mêmes. Le goulot d'étranglement de la revue. Les données GitHub montrent que les pushs de code mensuels ont dépassé 82 millions fin 2025, avec 41 % du nouveau code assisté par l'IA. Les pull requests s'accumulent. Les équipes rapportent attendre plus de 4 jours pour les revues. Le développeur a écrit le code en une heure, puis il reste dans la file de revue pendant une semaine. Une dette technique qui s'accumule différemment. Le code généré par l'IA a tendance à fonctionner mais manque de conscience architecturale. Les études montrent 4 fois plus de duplication de code et 60 % moins de refactoring dans les bases de code assistées par l'IA. La story de 3 points est livrée rapidement. Six mois plus tard, vous payez en maintenance. Tableau de sprint montrant un mélange de tickets complétés et bloqués, certains marqués comme terminés très rapidement et d'autres bloqués en revue de code, illustrant le flux inégal du développement assisté par IA Des développeurs juniors qui ressemblent à des seniors sur le papier. Un développeur avec deux ans d'expérience peut maintenant générer la même production qu'un développeur avec dix ans. Mais ils passent 1,2 minute à examiner chaque suggestion d'IA contre 4,3 minutes pour un senior. Cet écart de qualité n'apparaîtra qu'en production.

Les story points ne sont pas cassés, mais ils ont besoin d'un recalibrage

L'instinct d'abandonner complètement les story points est prématuré. Les points fonctionnent toujours pour l'alignement d'équipe et les conversations de planification de sprint. Ce qui doit changer, c'est la façon dont les équipes les calibrent.

Séparer "l'effort de codage" de "l'effort de livraison"

La partie que l'IA accélère (écrire du code) n'est qu'une pièce du cycle de vie d'une story. Une répartition plus honnête :

Phase	Impact de l'IA
Comprendre les exigences	Minimal
Écrire du code	Élevé (2-10x plus rapide sur le travail routinier)
Revue de code	Négatif (plus de code à réviser, souvent de moindre qualité)
Tests	Modéré (l'IA peut générer des tests, mais quelqu'un doit les vérifier)
Intégration et déploiement	Minimal

Si votre équipe estimait les stories principalement en fonction du temps de codage, vos points sont maintenant mal calibrés. Si vous estimiez en fonction de l'effort total de livraison, ils sont probablement plus proches de la précision.

Recalibrer vos stories de référence

Chaque équipe a des stories d'ancrage : "Vous vous souvenez de cette intégration de paiement ? C'était un 8." Ces ancres ont été fixées avant l'IA. Mettez-les à jour. Organisez une session de recalibrage où vous ré-estimez 5 à 10 stories terminées des deux derniers sprints. Utilisez votre outil de planning poker et demandez : "Sachant ce que nous savons maintenant sur la façon dont l'IA affecte ce type de travail, à combien l'estimerions-nous ?" Les écarts entre les anciennes et les nouvelles estimations vous indiqueront exactement où votre calibrage est décalé.

Autres façons de mesurer

Certaines équipes s'éloignent complètement des story points, et l'adoption de l'IA accélère ce changement. Le cycle time mesure le temps qu'un ticket prend du début à la fin. Il inclut le goulot d'étranglement de la revue et le pipeline de déploiement, pas seulement la rapidité avec laquelle quelqu'un a écrit le code. Les équipes qui suivent le cycle time constatent que l'IA fait à peine bouger l'aiguille sur la vitesse de livraison globale, même lorsque la vitesse de codage double. Le throughput compte combien d'éléments l'équipe termine par sprint, quelle que soit leur taille. Si votre équipe a livré 12 stories au sprint dernier et 14 ce sprint, c'est une information utile sans débattre de ce que signifie un "point". Les métriques DORA (fréquence de déploiement, délai de livraison, taux d'échec des changements, temps de restauration) se concentrent sur les résultats plutôt que sur la production. Lorsque l'IA rend le codage plus rapide mais que les taux d'échec des changements augmentent en raison d'une revue moins attentive, DORA montre le compromis que les chiffres de vélocité cachent. Tableau de bord montrant différentes métriques côte à côte, avec un graphique de vélocité traditionnel comparé aux graphiques de cycle time et de throughput, révélant différents schémas sur la performance de l'équipe Ron Jeffries, à qui l'on attribue souvent l'invention des story points, a déclaré : "J'ai peut-être inventé les story points, et si je l'ai fait, j'en suis désolé maintenant." Sa préoccupation était que les points soient mal utilisés comme mesure de productivité plutôt que comme outil de planification. L'IA aggrave cette mauvaise utilisation.

Ce qui fonctionne réellement en ce moment

D'après ce que les équipes rapportent début 2026 : Gardez le planning poker, mais changez la conversation. La réunion d'estimation reste précieuse. La discussion sur ce qui est impliqué dans une story est plus importante que le chiffre que vous assignez. Mais mettez à jour les questions : "L'IA aidera-t-elle avec cela ?" devrait faire partie de la conversation. Si une story est principalement du code répétitif, dites-le. Si c'est une intégration complexe où l'IA générera des solutions trompeuses, signalez-le aussi. Traitez le code généré par l'IA comme un premier jet, pas comme un travail fini. Intégrez le temps de revue dans vos estimations. Une story où l'IA a écrit 80 % du code pourrait nécessiter plus de temps de revue qu'une où un développeur a écrit chaque ligne, car le relecteur doit vérifier l'intention plutôt que simplement la qualité. Surveillez l'écart de perception. Rappelez-vous cette découverte de METR : les développeurs croyaient être 20 % plus rapides alors qu'ils étaient en réalité 19 % plus lents. Utiliser l'IA semble plus productif car générer du code est cognitivement plus léger que l'écrire à partir de zéro. Ce sentiment ne correspond pas toujours à l'horloge. Ne laissez pas cela gonfler vos engagements de sprint. Mesurez ce que vous livrez, pas ce que vous codez. Si le cycle time de votre équipe ne s'est pas amélioré malgré un codage plus rapide, le goulot d'étranglement est ailleurs. Corrigez-le avant de vous inquiéter des story points. Pour les équipes qui cherchent à expérimenter avec différentes échelles d'estimation pendant qu'elles recalibrent, Kollabe prend en charge Fibonacci, les tailles de T-shirt et les échelles personnalisées que vous pouvez adapter au fur et à mesure que votre équipe découvre ce qui fonctionne dans un flux de travail assisté par l'IA.

C'est un problème de processus

Les équipes qui gèrent bien cela n'ont pas acheté un outil d'estimation IA. Elles ont reconnu que l'IA a changé la façon dont leur travail est effectué et ont ajusté leur processus. Cela commence par des conversations honnêtes sur où l'IA aide et où elle ne le fait pas. Votre vélocité d'il y a six mois n'est plus une référence utile. Et l'écart entre la production de code et la livraison réelle n'a jamais été aussi large, alors concentrez-vous sur le côté de la livraison. Dernière mise à jour le 10/02/2026