Agentes de IA en tu sprint: cómo los copilots están cambiando el significado de un story point

Desarrollador trabajando con un asistente de programación con IA, una pantalla mostrando código siendo generado mientras la otra muestra un tablero de sprint con estimaciones de story points, transmitiendo la tensión entre la velocidad de la IA y la estimación tradicional Un ingeniero backend de tu equipo toma una historia de 5 puntos. Históricamente, eso es un día y medio de trabajo. Con Cursor y Claude, lo entrega en una hora. El siguiente sprint, el equipo mira un ticket similar y alguien pregunta: "¿Esto sigue siendo un 5?" Nadie tiene una buena respuesta. Esto está pasando en equipos de todas partes ahora mismo, y la mayoría del contenido sobre metodologías ágiles no se ha puesto al día.

El problema no es la inflación de velocidad

La reacción obvia es "genial, ahora somos más rápidos". Pero el problema es más profundo que números de velocidad más grandes. Los story points se supone que miden la complejidad relativa. Un 5 debería representar aproximadamente la misma cantidad de esfuerzo independientemente de quién lo tome. La IA rompe esa suposición de dos maneras: La aceleración es desigual. Un desarrollador junior usando Copilot podría ver un aumento de velocidad de 3x en un endpoint CRUD rutinario. Un desarrollador senior trabajando en una integración compleja con APIs desconocidas podría no ver mejora, o incluso ir más lento. El estudio METR de mediados de 2025 encontró que los desarrolladores experimentados de código abierto eran 19% más lentos con asistencia de IA en tareas del mundo real, mientras creían que eran 20% más rápidos. La misma persona es más rápida en algunas tareas pero no en otras. Los agentes de IA manejan bien el código repetitivo y patrones bien documentados. Tienen dificultades con decisiones arquitectónicas y cualquier cosa que requiera contexto profundo sobre tu base de código específica. Un desarrollador podría terminar tres historias de 3 puntos en una mañana, luego pasar dos días en una sola de 5 puntos donde la IA siguió generando soluciones plausibles pero incorrectas. Esto hace que la estimación sea extremadamente inconsistente. Tu gráfico de velocidad empieza a parecerse a un sismógrafo.

Lo que los equipos están experimentando realmente

Habla con gerentes de ingeniería dirigiendo sprints con equipos aumentados con IA y escucharás los mismos patrones: Números de velocidad que no significan nada. Un equipo reportó pasar de unos constantes 45-60 puntos por sprint a 55-65, pero el trabajo realizado no se sentía proporcionalmente diferente. El código más rápido no se estaba traduciendo en entrega más rápida porque los tiempos de revisión de código, QA y despliegue se mantuvieron iguales. El cuello de botella de la revisión. Los datos de GitHub muestran que los pushes de código mensuales superaron los 82 millones a finales de 2025, con 41% del nuevo código asistido por IA. Los pull requests se están acumulando. Los equipos reportan esperar más de 4 días para revisiones. El desarrollador escribió el código en una hora, luego queda en la cola de revisión por una semana. Deuda técnica que se acumula de manera diferente. El código generado por IA tiende a funcionar pero carece de consciencia arquitectónica. Los estudios muestran 4x más duplicación de código y 60% menos refactorización en bases de código asistidas por IA. La historia de 3 puntos se entrega rápido. Seis meses después estás pagando por ello en mantenimiento. Tablero de sprint mostrando una mezcla de tickets completados y atascados, con algunos marcados como terminados muy rápidamente y otros bloqueados en revisión de código, ilustrando el flujo desigual del desarrollo asistido por IA Desarrolladores junior que parecen seniors en papel. Un desarrollador con dos años de experiencia ahora puede generar la misma producción que alguien con diez. Pero pasan 1.2 minutos revisando cada sugerencia de IA comparado con los 4.3 minutos de un senior. Esa brecha de calidad no se mostrará hasta producción.

Los story points no están rotos, pero necesitan recalibración

El instinto de descartar los story points por completo es prematuro. Los puntos aún funcionan para la alineación del equipo y las conversaciones de planificación de sprint. Lo que necesita cambiar es cómo los equipos los calibran.

Separar "esfuerzo de codificación" de "esfuerzo de entrega"

La parte que la IA acelera (escribir código) es solo una pieza del ciclo de vida de una historia. Un desglose más honesto:

Fase	Impacto de IA
Entender requisitos	Mínimo
Escribir código	Alto (2-10x más rápido en trabajo rutinario)
Revisión de código	Negativo (más código para revisar, a menudo menor calidad)
Pruebas	Moderado (IA puede generar pruebas, pero alguien tiene que verificarlas)
Integración y despliegue	Mínimo

Si tu equipo estimaba historias principalmente basándose en el tiempo de codificación, tus puntos están ahora mal calibrados. Si estimabas basándote en el esfuerzo total de entrega, probablemente están más cerca de ser precisos.

Recalibra tus historias de referencia

Cada equipo tiene historias ancla: "¿Recuerdas esa integración de pagos? Esa fue un 8." Esas anclas se establecieron antes de la IA. Actualízalas. Ejecuta una sesión de recalibración donde re-estimas 5-10 historias completadas de los últimos dos sprints. Usa tu herramienta de planning poker y pregunta: "Sabiendo lo que sabemos ahora sobre cómo la IA afecta este tipo de trabajo, ¿en cuánto lo estimaríamos?" Las brechas entre las estimaciones antiguas y nuevas te dirán exactamente dónde está descalibrado.

Otras formas de medir

Algunos equipos se están alejando completamente de los story points, y la adopción de IA está acelerando ese cambio. Cycle time mide cuánto tiempo toma un ticket desde el inicio hasta completarse. Incluye el cuello de botella de la revisión y el pipeline de despliegue, no solo qué tan rápido alguien escribió el código. Los equipos que rastrean el cycle time están descubriendo que la IA apenas mueve la aguja en la velocidad general de entrega, incluso cuando la velocidad de codificación se duplica. Throughput cuenta cuántos ítems completa el equipo por sprint, independientemente del tamaño. Si tu equipo entregó 12 historias el sprint pasado y 14 este sprint, esa es información útil sin debatir qué significa un "punto". Métricas DORA (frecuencia de despliegue, lead time, tasa de fallos de cambios, tiempo de restauración) se enfocan en resultados en lugar de producción. Cuando la IA hace la codificación más rápida pero las tasas de fallos de cambios suben debido a una revisión menos cuidadosa, DORA muestra el trade-off que los números de velocidad ocultan. Dashboard mostrando diferentes métricas lado a lado, con gráfico de velocidad tradicional comparado con gráficos de cycle time y throughput, revelando diferentes patrones sobre el rendimiento del equipo Ron Jeffries, a quien se le atribuye frecuentemente la invención de los story points, ha dicho: "Puede que yo haya inventado los story points, y si lo hice, ahora lo lamento." Su preocupación era que los puntos se usan mal como una medida de productividad en lugar de una herramienta de planificación. La IA empeora ese mal uso.

Lo que realmente funciona ahora mismo

Basado en lo que los equipos están reportando a principios de 2026: Mantén el planning poker, pero cambia la conversación. La reunión de estimación sigue siendo valiosa. La discusión sobre lo que implica una historia es más importante que el número que le asignes. Pero actualiza las preguntas: "¿La IA ayudará con esto?" debería ser parte de la conversación. Si una historia es mayormente código repetitivo, dilo. Si es una integración compleja donde la IA generará soluciones engañosas, señálalo también. Trata el código generado por IA como un primer borrador, no trabajo terminado. Incluye el tiempo de revisión en tus estimaciones. Una historia donde la IA escribió el 80% del código podría necesitar más tiempo de revisión que una donde un desarrollador escribió cada línea, porque el revisor tiene que verificar la intención en lugar de solo la calidad. Observa la brecha de percepción. Recuerda ese hallazgo de METR: los desarrolladores creían que eran 20% más rápidos mientras en realidad eran 19% más lentos. Usar IA se siente más productivo porque generar código es cognitivamente más ligero que escribir desde cero. Esa sensación no siempre coincide con el reloj. No dejes que infle tus compromisos de sprint. Mide lo que entregas, no lo que codificas. Si el cycle time de tu equipo no ha mejorado a pesar de la codificación más rápida, el cuello de botella está en otro lugar. Arregla eso antes de preocuparte por los story points. Para equipos que buscan experimentar con diferentes escalas de estimación mientras recalibran, Kollabe soporta Fibonacci, tallas de camiseta y escalas personalizadas que puedes adaptar mientras tu equipo descubre qué funciona en un flujo de trabajo asistido por IA.

Este es un problema de proceso

Los equipos que están manejando esto bien no compraron una herramienta de estimación con IA. Reconocieron que la IA cambió cómo se hace su trabajo y ajustaron su proceso. Eso comienza con conversaciones honestas sobre dónde ayuda la IA y dónde no. Tu velocidad de hace seis meses ya no es una línea base útil. Y la brecha entre la producción de código y la entrega real nunca ha sido más amplia, así que enfócate en el lado de la entrega. Última actualización el 10/02/2026