Por qué Scrum no muere con la llegada de los agentes de IA — pero tampoco sobrevive intacto
El punto de partida
Todo el mundo asume que si los agentes de IA escriben el código, los sprints se acortan, los equipos entregan más rápido, y Scrum tal como lo conocemos se vuelve obsoleto por lento. Es una conclusión intuitiva. También es, en mi opinión, parcialmente equivocada.
La generación de código escala con cómputo. La capacidad de un humano para revisar ese código con criterio — para decidir si debe llegar a producción — no escala igual. Si un agente te entrega 500 líneas en dos minutos y te toma diez revisarlas bien, el límite real del sistema nunca fue la velocidad de generación. Es cuántas revisiones de calidad puede hacer un humano por día.
Eso cambia todo el análisis.
Lo que se mantiene: el esqueleto de valores
Scrum, en el fondo, es un marco de tres cosas: transparencia (todos ven el mismo estado real), inspección (revisas seguido, no al final) y adaptación (cambias de rumbo rápido). Nada de esto depende de si quien "hace" el trabajo es humano o agente. Si acaso, la necesidad de iterar corto y revisar seguido se vuelve más importante cuando el volumen de output se dispara.
Lo que muta: las ceremonias se redefinen alrededor del review, no de la escritura
Sprint Planning deja de ser "¿qué historias entran esta iteración?" y pasa a ser "¿qué specs están lo suficientemente claras para que un agente no alucine?". Esto es trabajo nuevo: antes, la ambigüedad la resolvía el dev sobre la marcha mientras codeaba. Ahora tiene que estar resuelta antes, por escrito, o el agente rellena los huecos con suposiciones.
Una spec "lista para agente" necesita, como mínimo:
- Un contrato de entrada/salida explícito — no "el endpoint de login", sino el shape exacto del request/response y qué pasa en cada caso límite.
- Restricciones de arquitectura ya resueltas: qué patrón usar, qué no tocar. Hoy esto vive en la cabeza del dev senior; con agentes tiene que estar escrito.
- Criterios de aceptación como casos de test concretos, no como prosa ("debe validar bien los datos" no sirve).
- Contraejemplos explícitos — qué NO hacer — porque los agentes repiten antipatrones si nadie se los marca.
La consecuencia incómoda: el planning probablemente se alarga, no se acorta. El trabajo de pensar se mueve del "durante" (mientras codeas) al "antes" (mientras especificas). Es el mismo total de esfuerzo cognitivo, solo que concentrado al inicio.
Daily se vuelve menos "¿qué hiciste ayer?" y más "¿dónde está atorado el agente, y dónde estoy atorado yo revisando?". El reporte de bloqueo cambia de "trabajo pendiente" a "contexto faltante" o "cola de revisión".
Sprint Review gana peso relativo — es el único punto donde un humano de negocio valida que lo generado realmente sirve, no solo que pasa los tests.
Retro se parte en dos preguntas que hoy están mezcladas: qué mejoramos del proceso humano, y qué mejoramos del contexto/prompts/guardrails del agente. La segunda se parece más a MLOps que a retro tradicional.
Lo que cambia de fondo: la unidad de trabajo
Hoy la unidad es la historia de usuario, dimensionada en story points para que quepa en el sprint de una persona. Con agentes, el tamaño de la tarea deja de estar limitado por cuánto puede teclear un humano en dos semanas. El límite pasa a ser cuánto contexto no ambiguo le puedes dar al agente de una vez.
La consecuencia es contraintuitiva: agentes más capaces no significa tareas más grandes, sino specs más atómicas — porque la ambigüedad se paga cara a escala.
Qué reemplaza a story points
Story points miden esfuerzo relativo de un humano escribiendo código. Si eso deja de ser el cuello de botella, medirlo pierde sentido. Candidatos más coherentes con este nuevo mundo:
- Tiempo de revisión estimado, no de generación. Una tarea "grande" ya no es la que tarda en codearse, sino la que tarda en verificar — por superficie de cambio, criticidad, o contexto de negocio que exige.
- Densidad de ambigüedad de la spec: cuántas decisiones quedaron sin resolver antes de mandarle la tarea al agente.
- Blast radius / criticidad: no es lo mismo tocar una página estática que el módulo de pagos. Esto se parece más a cómo se estima riesgo en seguridad (impacto × probabilidad) que a Scrum clásico.
- Tasa de aceptación en primera pasada: qué porcentaje del output del agente pasa review sin cambios mayores. Mide la calidad del sistema (contexto, prompts), no del trabajo puntual — sirve para mejorar el proceso, no para planear el sprint.
El punto de fondo: estimar deja de ser "cuánto esfuerzo humano toma escribir esto" y pasa a ser "cuánto esfuerzo humano toma confiar en que esto está bien". Es una pregunta de naturaleza distinta, y nadie ha formalizado todavía el "planning poker" de esto.
Una nota de cautela sobre las métricas nuevas
Cuidado con métricas tipo "cuántos PRs generó el agente y cuántos aceptó el humano" (agent throughput). En cuanto una métrica se vuelve la meta, la gente optimiza para que suba el número, no para que mejore la calidad — ya lo vimos con "líneas de código" en los 90s. Una métrica más honesta apunta a defectos escapados a producción por sprint, o tiempo de review ponderado por complejidad: mide la calidad del filtro, no el volumen que pasa por él.
Por qué esto no será parejo
CRUD, dashboards, integraciones estándar, proyectos greenfield: ahí la transformación se ve rápido y clara. Pero en legacy sin tests, dominios con reglas de negocio implícitas y nunca documentadas, o contextos regulatorios (fintech, salud, gobierno), el cuello de botella sigue siendo explicarle al agente años de decisiones tácitas que nadie escribió — y eso no lo resuelve el mejor RAG del mercado. Ahí el sprint de dos semanas probablemente sobrevive más tiempo del que la narrativa optimista sugiere, y no por resistencia al cambio sino por razones regulatorias y de auditoría que no son técnicas.
La apuesta
Scrum no muere. Pero dentro de tres a cinco años, lo que hoy llamamos "Scrum" probablemente se parezca más a un framework de gobernanza de agentes con vocabulario ágil prestado, que al Scrum de 2015 enfocado en coordinar humanos escribiendo código a mano.
El dev, mientras tanto, no desaparece — se convierte en el filtro más importante del sistema. Y ese filtro, a diferencia del código que revisa, no se puede generar en dos minutos.
Top comments (0)