Cómo cambia el trabajo de un Scrum Team cuando la IA entra en el flujo de desarrollo.
Antes de esta sesión — ¿dónde está tu equipo con la IA?
Los Sprints de dos semanas se diseñaron para un mundo donde escribir código llevaba tiempo. Ese mundo ya no existe. Con IA, una funcionalidad pasa de idea a código funcionando en minutos. Para eso no hacen falta ceremonias.
¿Es esto cierto? Vamos a comprobarlo.
Pregunta guía: ¿Qué cambia de verdad cuando la IA se une al equipo?
Scrum se diseñó para problemas complejos — donde ni los requisitos ni el camino hacia la solución están claros de entrada.
Aquí vive ScrumLos Sprints son ciclos de dos semanas para producir output.
Entran historias, sale código, la Demo es un checkpoint.
La velocity es la estrella polar.
"Done" significa que el código está mergeado.
No se está respondiendo a ninguna pregunta.
Resultado: output rápido, dirección desconocida.
Cada Sprint arranca con un Sprint Goal — una hipótesis.
La Review es una sesión de feedback, no una demo.
El impacto es la estrella polar.
"Done" significa que se ha aprendido algo.
Cada Sprint responde a una pregunta concreta.
Resultado: más lento en features, más rápido en valor.
Las razones por las que nació Scrum siguen vigentes: los mercados cambian, los usuarios nos sorprenden, la tecnología se comporta de forma inesperada.
El mayor peligro para Scrum no es Waterfall, ni la IA — es Scrum reducido a una cadencia de reuniones sin empirismo.
Si tus Sprints responden preguntas reales, la IA hace Scrum más potente. Si son solo ciclos de output, la IA hace el problema más grande.
Ideal para exploración y prototipado rápido. El desarrollador se mantiene en flujo creativo — sin boilerplate, sin cambios de contexto.
Trade-off: alto potencial de deuda técnica y comportamientos indefinidos en los bordes.
El desarrollador escribe especificaciones detalladas; la IA genera código de calidad de producción. Menos ambigüedad, menos deuda.
Trade-off: exige pensamiento disciplinado por adelantado — más difícil de empezar, mucho más fácil de mantener.
El agente de IA ejecuta tareas de varios pasos de principio a fin: escribe, testea, corrige, hace commit. El equipo revisa los resultados y aprueba las decisiones.
Trade-off: el mayor apalancamiento, pero exige prácticas de validación maduras y límites claros de autonomía.
La IA ha ampliado drásticamente el throughput de Delivery — lo que antes llevaba semanas ahora lleva horas.
La restricción ya no es escribir código. Es decidir qué merece la pena construir — filtrar la demanda, enmarcar el problema, elegir qué no hacer.
La velocidad no es el problema. La desconexión estratégica sí lo es — y la IA la amplifica.

El modelo lógico (Seiden) muestra qué conecta el esfuerzo con el valor. La IA acelera drásticamente los Outputs. El problema: los equipos celebran la velocidad de output como si fuera velocidad de outcome.
Sin Sprint Goals y Product Goals claros, más output solo significa más ruido.
A medida que aumenta el ritmo de entrega, el desfase entre lo que publicamos y lo que medimos —cambio de comportamiento de usuario, retención, conversión— crece de forma proporcional.
Volar a ×17 de velocidad sin señales de outcome es navegar a ciegas. Cuanto más rápido vas, más necesitas una brújula.
Demasiadas altas se dan de baja antes del mes 3. GymTonic quiere reducir el churn temprano y aumentar el lifetime value de cada socio.
Hipótesis: si los socios nuevos llegan a 8 visitas en 30 días, la retención a 90 días sube. La app existe para conseguirlo.
El resultado estratégico que persigue el equipo en esta fase del producto.
No es una lista de features. No es el alcance de un proyecto.
Una hipótesis sobre impacto: "Si los nuevos socios de GymTonic llegan a 8 visitas en sus primeros 30 días, reducimos el churn a 90 días un 20%."
Cada ítem del backlog se evalúa contra este filtro antes incluso de discutirlo.
La pregunta concreta que este Sprint va a responder.
No es un Sprint backlog. No es un compromiso de features.
Un objetivo de aprendizaje: "Creemos que reservar las 3 primeras sesiones durante el onboarding aumentará la asistencia en la semana 1."
El Daily Scrum pregunta: ¿seguimos en camino de responder esta pregunta?
Los tres pilares: Transparencia, Inspección, Adaptación.
La necesidad de un Product Goal claro.
El valor de un equipo multifuncional y autogestionado.
Ciclos cortos con feedback real.
El criterio humano en los puntos de decisión.
La duración del Sprint puede acortarse — generar código ya no es la restricción.
El foco del Daily pasa de reportar progreso a validar output.
El Refinement se convierte en trabajo de especificación — el input para la generación con IA.
La Review pasa de demo de features a conversación sobre resultados.
La Definition of Done tiene que subir al ritmo de la velocidad de output.
Acortar los Sprints no va de ir más rápido. Va de aprender más rápido — reducir el tiempo entre una hipótesis y su primera señal real.
Si tu DoD es la misma que antes de la IA, estás acumulando riesgo invisible.
Pasa de sincronizar progreso a validar output y revisar decisiones de la IA.
Las preguntas que importan ahora:
Pasa de demo de features a conversación sobre resultados.
Las preguntas que importan ahora:
Pasa de fricción de proceso a calidad de la colaboración humano-IA.
Las preguntas que importan ahora:
Se convierte en validador de hipótesis, no en aprobador de features.
El backlog es un conjunto de apuestas, no una lista de tareas. El trabajo del PO es maximizar la relación señal-ruido: ¿qué apuestas merece la pena correr este Sprint?
La habilidad clave: traducir resultados de negocio en Sprint Goals verificables.
Se convierte en facilitador del aprendizaje humano-IA, no en gestor de reuniones.
Ayuda al equipo a construir la disciplina de especificar bien, validar con rigor y mejorar el bucle de colaboración. Elimina impedimentos para supervisar con eficacia el output de la IA.
Se convierten en arquitectos y supervisores del output de la IA, no en operadores de prompts.
Diseñan el sistema, escriben las especificaciones que producen código de calidad, revisan lo que genera la IA y son dueños de la Definition of Done. La IA ejecuta; los developers juzgan.
"Como socio de GymTonic quiero recordatorios de clase para no perderme mis sesiones."
"Creemos que recordar a los socios 2 h antes de una clase reservada sube la asistencia ×1,5. Lo probaremos con el 20% de los socios de GymTonic en el Sprint 8."
El Spec-Driven Development cambia el formato de la especificación. El cambio de arriba cambia su propósito.
Más ideas que nunca. Más peticiones de stakeholders. Más posibilidades técnicas. La capacidad de filtrar, priorizar y decir que no es ahora la habilidad más valiosa —y más escasa— del equipo.
El Product Goal no es un artefacto de planificación. Es el filtro que protege al equipo de ir muy rápido en la dirección equivocada.
Los equipos que dominen la gestión de la demanda en la era de la IA construirán diez veces más valor con la misma gente. Los que no, construirán diez veces más desperdicio.
Scrum no se diseñó para producir rápido — de producir se encarga la IA ahora. Lo que Scrum aporta es un marco para aprender rápido: hipótesis claras, ciclos cortos, resultados validados.
El equipo que gana en la era de la IA no es el que más publica. Es el que responde más rápido a las preguntas correctas.
Si haces una sola cosa: escribe un Product Goal antes de tu próxima Sprint Planning — el resultado que persigues, por qué importa ahora, y cómo sabrás que lo has conseguido.
La velocidad no es el problema. El problema es ir muy rápido en la dirección equivocada.
Alex Ballarín · Professional Scrum Trainer · ITNOVE