Cuando la tecnología con la que se construye el producto cambia, los modelos de gestión necesitan revisarse. Es una premisa que la industria del software ha aplicado con diferente velocidad en cada transformación tecnológica. Con la IA generativa, el cambio es lo suficientemente profundo como para que valga la pena hacer el ejercicio práctica por práctica, sin asumir que todo el catálogo heredado de la comunidad ágil sigue siendo válido tal como está.

Lo que sigue no pretende ser definitivo. Es un mapa del territorio tal como lo vemos actualmente, combinando lo que está documentando la investigación con lo que tiene sentido a nivel conceptual. Cada equipo tendrá que encontrar su propio camino.

Burn down y burn up: cuando el gráfico miente sin que nadie mienta

El gráfico de avance tiene una función clara: hacer visible el ritmo de trabajo del equipo dentro del sprint, de forma que las desviaciones aparezcan pronto y den pie a conversaciones en el daily. Esa función no desaparece con la IA.

Lo que cambia es la señal que el gráfico puede estar midiendo. La investigación de DORA 2025 muestra que la IA aumenta el volumen de PRs de forma significativa, generando una tensión directa con la práctica de trabajar en lotes pequeños, que es una de las capacidades que más amplifica el impacto positivo de la IA. Es decir, si la IA genera código más rápido de lo que el equipo puede revisar, el burn down puede mostrar puntos completados que en realidad están pendientes de revisión humana. El sprint se ve en verde mientras la deuda técnica crece sin que nadie la haya contabilizado.

La respuesta no es abandonar el gráfico, sino complementarlo. Indicadores de calidad del código (cobertura de tests, duplicación, complejidad ciclomática) junto a los puntos completados dan una imagen más honesta de lo que está ocurriendo. Hay quien recomienda convertir la auditoría continua de salud del código en una práctica explícita, no en algo que se revisa cuando hay un problema.

Una propuesta que merece exploración: añadir una línea de «revisión pendiente» al burn down, que refleje específicamente el código generado por IA que aún no ha pasado la revisión humana. Eso haría visible el cuello de botella real antes de que llegue a la retrospectiva.

Kanban: el flujo continuo como ventaja, con un riesgo nuevo

El tablero kanban, con sus estados y sus límites de WIP, encaja bien con el nuevo contexto. Cuando la variabilidad técnica de la ejecución se reduce, el flujo continuo sin timeboxing puede adaptarse mejor que el sprint a la realidad de cómo trabaja el equipo. El principio de trabajar en lotes pequeños amplifica el impacto positivo de la IA, y el WIP es precisamente el mecanismo que impone ese límite.

Pero hay un riesgo específico que el tablero tradicional no hace visible: la asimetría entre la velocidad de generación y la velocidad de revisión. Un agente puede generar código en minutos; la revisión humana puede llevar horas. Si el tablero trata la tarea como «en curso» desde que el agente empieza hasta que la revisión humana termina, esconde ese cuello de botella. Una adaptación posible es añadir un estado explícito de «generado / pendiente de revisión» entre «en curso» y «terminado». Eso hace visible cuántas tareas están esperando revisión humana en cada momento y convierte el WIP en un limitador real del cuello de botella, no solo del volumen de trabajo iniciado.

Planning poker: el valor está en la conversación, no en el número

El planning poker lleva más de dos décadas en el repertorio ágil. Lo formalizó James Grenning en 2002 y lo popularizó Mike Cohn en Agile Estimating and Planning (2005). Su valor siempre fue producir estimaciones más calibradas a través del consenso y, sobre todo, generar conversación sobre el trabajo antes de hacerlo. La estimación simultánea previene el sesgo de anclaje; la discusión entre quienes votan valores extremos aflora conocimiento que de otro modo permanece tácito.

Ninguno de esos mecanismos desaparece cuando hay IA en el equipo. Lo que cambia es la premisa sobre la que se construyó la técnica: la variabilidad del esfuerzo humano como razón principal para usar unidades relativas. Cuando parte del trabajo lo ejecuta un agente, esa variabilidad se redistribuye. El esfuerzo cognitivo se desplaza de implementar a especificar, revisar y validar. Y esas tareas tienen su propia dificultad, que no siempre encaja bien en la escala de story points diseñada para trabajo de implementación directa.

El AI4Agile Practitioners Report 2026 identifica la incertidumbre de integración como el principal obstáculo para adoptar IA: el 54,3% de los encuestados no saben cómo encaja la IA en la sprint planning, en el refinamiento o en la retrospectiva. El planning poker es uno de esos espacios sin respuesta clara.

Lo que se está explorando va en dos direcciones:

• Adaptar la estimación: distinguir explícitamente entre tareas que ejecutará la IA (donde el esfuerzo humano es principalmente de especificación y revisión) y tareas que requieren juicio humano (donde la estimación clásica sigue teniendo sentido).
• Reforzar el argumento del movimiento #NoEstimates: cuando la variabilidad técnica de la ejecución se reduce, el coste de estimar puede superar el valor que aporta.

Lo que parece resistir el cambio de contexto es el valor más profundo del planning poker: la conversación que genera. Un equipo que usa la sesión de estimación para hablar sobre qué implica construir algo, qué riesgos hay y quién sabe qué, sigue teniendo una razón sólida para practicarla.

Estimación en la pared y tallas de camiseta: la intuición colectiva sigue siendo valiosa

Estas técnicas son esencialmente mecanismos de alineación visual y colectiva. Su propósito no es la precisión numérica sino crear entendimiento compartido sobre el tamaño relativo del trabajo. En ese sentido son más robustas al cambio de contexto que el planning poker clásico: no dependen de una premisa sobre el tipo de esfuerzo involucrado, sino de la capacidad del equipo para comparar trabajo y construir criterio compartido.

La única tensión relevante es que, si parte del trabajo lo ejecuta la IA, las referencias intuitivas del equipo pueden desactualizarse. Una historia que antes era «M» puede haber pasado a ser «S» porque la implementación es ahora asistida, pero el esfuerzo de especificación y revisión sigue siendo comparable al anterior. Revisitar periódicamente qué significa cada talla en el contexto actual del equipo es una práctica sana que la IA hace más necesaria.

TDD

Este es quizás el caso más claro de práctica que la IA refuerza en lugar de cuestionar. El informe DORA 2025 confirma que el TDD amplifica el impacto positivo de la IA: dado que la IA actúa como un amplificador de lo que ya existe en el equipo, las prácticas fundacionales como el TDD se vuelven más críticas, no menos.

El motivo es concreto: un taller ágil reciente concluyó que el TDD produce resultados dramáticamente mejores con agentes de IA porque previene un fallo específico: que el agente escriba tests que verifican comportamiento incorrecto. Cuando los tests existen antes del código, el agente no puede «hacer trampa» escribiendo un test que simplemente confirma la implementación incorrecta que él mismo produjo.

La comunidad está documentando una práctica emergente derivada: el Test-Driven Generation (TDG), propuesto por Chanwit Kaewkasi. La idea es combinar TDD con IA de forma que el desarrollador actúa como especificador —proporciona los requisitos en alto nivel— la IA genera los tests basándose en esos requisitos, y después genera el código que debe pasar esos tests. El desarrollador revisa y valida. El ciclo Red-Green-Refactor se mantiene, pero quien ejecuta los pasos cambia. El valor de la práctica original —primero definir qué debe hacer el código, luego hacerlo— se refuerza.

Diagramas para retrospectivas: el espacio de reflexión se vuelve más necesario

Los diagramas de espina de pez e Ishikawa y los diagramas de árbol son herramientas de estructuración del pensamiento colectivo. No hay ninguna razón para que la IA los haga obsoletos. Al contrario: los usos más exitosos de la IA en retrospectivas son acotados y de bajo riesgo: preparar la sesión, agrupar feedback cualitativo, generar primeros borradores de análisis de causas.

Lo que cambia es el contenido de la conversación que estos diagramas ayudan a estructurar. En equipos con IA la espina de pez puede aplicarse a problemas nuevos: ¿por qué el código generado está acumulando deuda técnica? ¿Por qué el equipo no confía en los outputs del agente? ¿Por qué la velocidad aparente es alta pero el valor entregado no lo es? Estos son problemas causales que merecen el mismo análisis estructurado que cualquier otro.

Una propuesta de práctica emergente: la «retrospectiva de gobernanza IA», que dedica periódicamente (no necesariamente cada sprint) un tiempo específico a examinar cómo está funcionando la integración de la IA en el proceso del equipo, usando los mismos diagramas de causa-efecto. No para juzgar si se usa o no, sino para hacer consciente lo que ocurre por inercia.

Conclusión

Las prácticas que sobreviven mejor al cambio de contexto son las que siempre dependieron del juicio humano y la conversación colectiva: la retrospectiva, el planning poker como generador de conversación. Las que necesitan revisión son las que miden el trabajo asumiendo que solo hay humanos ejecutando: el burn down clásico, el WIP sin estado de revisión. Las que se refuerzan son las que siempre fueron controles de calidad: el TDD, las técnicas a prueba de errores.

Y hay una categoría que no se cubría porque el problema no existía: cómo hacer visible la asimetría entre velocidad de generación y capacidad de revisión humana. Ahí es donde la comunidad está inventando cosas nuevas, con diferente nivel de madurez. La mayoría son adaptaciones de herramientas existentes, no reinvenciones. Lo cual tiene sentido: scrum siempre evolucionó así.

¿Con qué prácticas estás teniendo más fricciones en tu equipo desde que empezasteis a usar IA? ¿Hay algo que hayáis modificado que esté funcionando?

Bibliografía

• Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall.
• Grenning, J. (2002). Planning Poker or How to Avoid Analysis Paralysis while Release Planning. Renaissance Software Consulting.
• Google Cloud / DORA (2025). State of AI-Assisted Software Development.
• Kaewkasi, C. (2025). Test-Driven Generation (TDG): Adopting TDD Again This Time with Gen AI. Medium.
• McKinsey & Company (2025). The State of AI: How Organizations Are Rewiring to Capture Value. McKinsey QuantumBlack.
• Vacanti, D. S. (2015). Actionable Agile Metrics for Predictability. ActionableAgile Press.
• Wolpers, S. (2025).
  • Scrum Anti-Patterns Guide. Pearson.
  • AI4Agile Practitioners Report 2026. Age-of-Product / Scrum.org.
• Sutherland, J., Coleman, J. & Jocham, R. (2025). Scrum Guide Expansion Pack.