Tiempo de lectura: 9 minutos
Cada pocas semanas alguien anuncia que la IA ha matado a Scrum. Si Scrum fuera una forma de repartir tareas en Sprints de dos semanas, tendría razón: para coordinar tareas ya hay tableros, Kanban y agentes que lo hacen más rápido.
Pero Scrum nunca fue eso. Nació para trabajar en lo complejo, ha cambiado con cada ola del software y, con la IA, tiene más sentido que antes. Eso sí: no el Scrum mecánico, sino uno que dirige el trabajo hacia resultados.
- Por qué te importa: con agentes de IA, tu equipo puede producir mucho más código que antes, y la pregunta ya no es cómo coordinar tareas, sino cómo decidir qué vale la pena entregar.
- Qué aporta este artículo: cómo ha evolucionado Scrum desde los 90, por qué está pensado para metas y no para tareas, qué dice el estudio del NBER sobre el código que generan los agentes y cómo situar las Metas de Producto y de Sprint en el modelo lógico.
- Qué te llevas: ejemplos de metas a nivel de output, outcome e impacto, y cinco cambios para un Scrum más estratégico, conectado con los OKR y el product management.
Scrum no ha sido siempre lo mismo: cómo ha cambiado con el software
Scrum lleva más de treinta años adaptándose a cómo se hace software. Visto de lejos, el recorrido es este:
| Época | Cómo se hacía software | Qué cambió en Scrum |
|---|---|---|
| Años 90 | Proyectos en fases (análisis, diseño, desarrollo, pruebas) y entregas cada varios meses | Nace con ciclos cortos y equipos que se organizan solos |
| Años 2000 | Programación extrema, integración continua y pruebas automáticas | «Hecho» pasa a significar integrado y probado al final de cada Sprint |
| Años 2010 | Entrega continua, cloud y microservicios: se despliega varias veces al día | Se puede entregar más de un incremento por Sprint; la Sprint Review deja de ser una puerta para salir a producción |
| Lean y Kanban | Flujo, límites de trabajo en curso y métricas de tiempo de ciclo | Scrum con Kanban: el flujo se gestiona dentro del Sprint |
| Ahora | Agentes de IA que escriben buena parte del código | El cuello de botella pasa a descubrir, validar y decidir |
Cada cambio técnico movió el foco de Scrum un paso más allá de la ejecución. Cuando desplegar dejó de ser un acontecimiento, el Sprint dejó de ser «el paquete que entregamos» y pasó a ser el ciclo en el que aprendemos. La Guía de Scrum de 2020 lo dejó escrito al añadir la Meta de Producto. Lo conté con más detalle en Cómo ha evolucionado Agile: de proceso a producto, resultado e impacto.
Scrum está pensado para metas, no para tareas
El origen lo explica. En 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaron en Harvard Business Review un artículo sobre cómo desarrollaban productos nuevos empresas como Honda, Canon o Fuji-Xerox. En vez de pasar el trabajo de un departamento a otro, como en una carrera de relevos, usaban un equipo pequeño y multidisciplinar que avanzaba junto, «como en el rugby». De ahí sale el nombre.
Lo interesante es cómo los dirigían: la dirección marcaba una meta amplia y exigente y daba libertad al equipo para encontrar cómo llegar. Nada de un plan detallado. Era una forma de gestionar lo complejo: cuando no sabes de antemano la solución, fijas el destino y aprendes por el camino. Jeff Sutherland y Ken Schwaber llevaron esa idea al software a mediados de los 90.
Evidence-Based Management (EBM), el marco de Scrum.org para medir el valor, lo ordena en tres niveles de metas:
- La meta estratégica es lejana y ambiciosa: no se sabe si se llegará ni cómo.
- La meta intermedia es un hito que indica que vas bien. En Scrum se parece a la Meta de Producto.
- La meta táctica inmediata es lo que el equipo intenta ahora. En Scrum se parece a la Meta de Sprint.
Entre la situación actual y cada meta hay un bucle de experimentos: hipótesis, prueba, mirar el resultado y adaptar. Es el mismo razonamiento que el PDCA de la mejora continua. Si quieres verlo con un caso, en Qué es Evidence-Based Management y en las metas estratégicas de EBM lo desarrollo con GymTonic, el caso que usamos en formación.
Los agentes aceleran el delivery, y también el código que no llega a ningún sitio
Aquí es donde la IA cambia el juego. Mert Demirer, Leon Musolff y Liyuan Yang publicaron en el NBER un estudio con datos de cientos de miles de desarrolladores de GitHub que usan herramientas de IA, desde el autocompletado hasta los agentes que trabajan solos. Su título lo resume: escribir código no es lo mismo que entregarlo (NBER, 2026).
El código se multiplica por 17, y las releases, por 1,3. En la revisión del estudio, el código llega a multiplicarse por 25,5 y las releases siguen igual. ¿Dónde se queda todo lo demás?
Según los autores, en experimentación que no llega a ningún sitio. Con agentes, los desarrolladores añaden siete veces más líneas, pero borran doce veces más: buena parte de lo que se escribe se reescribe o se tira. Crecen los proyectos que se abandonan al mes de empezar. Y en las tiendas de aplicaciones aparecen muchas más apps nuevas, pero el uso total no sube.
La explicación es sencilla: la parte lenta es humana. Revisar, decidir qué entra, validar con usuarios y salir a producción no va a la velocidad de un agente. Si el equipo mide su avance por lo que genera, acelera justo la parte que no era el problema. Lo desarrollé en Generar código sin revisar no escala y en Generar código con IA es fácil; crear impacto, no tanto.
Metas de Producto y de Sprint: del output al impacto
Para que Scrum dirija y no solo coordine, las metas tienen que estar en el sitio correcto. El modelo lógico de proyecto ayuda a verlo: separa lo que se invierte, lo que se hace, lo que se entrega (output), lo que cambia para el cliente (outcome) y lo que gana la empresa (impact).
Las Metas de Producto pueden estar en cualquiera de los tres niveles. Las de Sprint suelen ser más tácticas, algo más a la izquierda, porque dos semanas (o tres días) dan para mover un resultado, rara vez el impacto. Con GymTonic, el caso de formación:
| Nivel | Meta de Producto | Meta de Sprint |
|---|---|---|
| Output | «Lanzar la reserva de clases en la app» | «Los socios pueden reservar clase desde la app» |
| Outcome | «Los socios nuevos reservan su primera clase en la primera semana» | «Saber si los socios de un gimnasio piloto repiten la reserva desde la app» |
| Impact | «Menos bajas en los tres primeros meses» | (rara vez cabe en un Sprint) |
Si todas tus metas están en la fila de output, Scrum se queda en coordinar tareas, y para eso Kanban o los agentes van más rápido. El valor aparece cuando la Meta de Producto está en outcome o impacto y la de Sprint dice qué se quiere aprender o cambiar, no solo qué se entrega. Más sobre el modelo en El modelo lógico de proyecto y sobre la Meta de Producto en Scrum necesita un evento de planificación de la Meta de Producto.
Un Scrum más estratégico: autonomía, OKR y product management
Con la IA, ejecutar sale barato. Eso abre una oportunidad: que el equipo se acerque a la autonomía de verdad, la de decidir cómo llegar a un resultado, y no solo cómo repartir tareas. Para eso hacen falta dos cosas que Scrum ya tiene sitio para recibir.
La primera es una estrategia que se delega. Con OKR, dirección define el objetivo y los resultados clave, y el equipo decide cómo alcanzarlos. La Meta de Producto se conecta con un resultado clave, y cada Sprint acerca a ese resultado. Lo explico en Añade los OKR a tu panel de producto.
La segunda es product management. El Product Owner deja de ser quien ordena el backlog y pasa a decidir dónde está el valor: qué problema del cliente se ataca, cómo se valida y cuándo se para. Cuando los agentes construyen rápido, esa decisión es la que más vale.
En la práctica, cinco cambios para el próximo Sprint:
- Escribir la Meta de Producto como resultado o impacto, no como una lista de funcionalidades.
- Que la Meta de Sprint diga qué se quiere aprender o cambiar, y conectarla con un resultado clave.
- Revisar evidencias en la Sprint Review: datos de uso y lo que dicen los usuarios, no solo una demo.
- Dejar la coordinación de tareas al tablero y a los agentes, y centrar el Daily en cómo va la meta.
- Acortar el Sprint cuando validar es barato (p.e. tres días con tres personas), para aprender más veces.
Si quieres probarlo con tu equipo, Cómo crear OKR de producto con IA es un buen punto de partida. Y en Scrum e IA: ¿aliados o rivales? tienes el resumen del webcast que hicimos sobre este tema.
Preguntas frecuentes
¿La IA ha matado a Scrum?
No. La IA hace innecesario el Scrum que solo sirve para coordinar tareas, porque los tableros y los agentes lo hacen mejor. Pero Scrum nació para trabajar en lo complejo con metas y ciclos cortos de aprendizaje, y eso es justo lo que falta cuando el código se escribe solo y lo difícil es decidir qué entregar.
¿Para qué sirve Scrum si los agentes de IA programan?
Para decidir qué vale la pena construir y comprobar si funciona. El estudio de Demirer, Musolff y Yang (NBER, 2026) muestra que la IA multiplica el código mucho más que las releases: el cuello de botella está en revisar, validar y decidir, que son tareas humanas y son las que ordenan las metas, la Sprint Review y la retrospectiva.
¿Qué diferencia hay entre la Meta de Producto y la Meta de Sprint?
La Meta de Producto es un objetivo a medio plazo del producto y puede estar a nivel de output, de resultado para el cliente o de impacto para la empresa. La Meta de Sprint es el objetivo de un Sprint: más táctica, suele estar en output o en resultado, y funciona mejor cuando dice qué se quiere aprender o cambiar.
¿Cómo se combinan Scrum y OKR?
Dirección define con OKR el objetivo y los resultados clave, y el equipo de Scrum decide cómo alcanzarlos. La Meta de Producto se conecta con un resultado clave, las Metas de Sprint acercan a ese resultado y la Sprint Review revisa si se está moviendo.
Recursos relacionados