Eliyahu M. Goldratt formuló en su teoría de restricciones (TOC) una idea sencilla pero de consecuencias profundas: todo sistema está limitado por al menos una restricción que determina su rendimiento global. Da igual cuánto optimices el resto del sistema: si no identificas y actúas sobre esa restricción, no mejorarás. La metáfora clásica es la de la cadena y su eslabón más débil.

Lo que hace particularmente relevante a la TOC en este momento es su quinto paso: una vez que has roto una restricción, debes volver al principio y buscar la nueva. Y, sobre todo, no dejar que la inercia (las reglas, procesos y hábitos construidos alrededor de la restricción anterior) se convierta ella misma en la siguiente restricción.

Esto es exactamente lo que está ocurriendo en muchos equipos Scrum que incorporan IA. Durante años, la restricción dominante era la capacidad de construcción: el equipo podía idear más de lo que podía construir. La IA ha roto esa restricción. Un agente puede generar en minutos un módulo que antes costaba días. Pero esa velocidad de generación no se traduce automáticamente en velocidad de entrega, porque la restricción se ha desplazado a otro punto del sistema. ¿A cuál? Depende del equipo, pero hay patrones que se repiten.

Revisar, integrar, validar

La guía Scrum en equipos con IA de Scrum Manager identifica tres niveles de trabajo en los equipos que combinan inteligencia humana y artificial: tareas automatizadas (que la IA ejecuta de forma autónoma), tareas humanas (que requieren creatividad, juicio o negociación) y tareas de revisión e integración (R&I), que consisten en revisar, validar e integrar lo que genera la IA. De las tres, las tareas R&I son, según la propia guía, "el tipo de tarea más fácil de subestimar y el que genera más cuellos de botella".

¿Por qué? Porque un agente IA puede generar código en minutos, pero la revisión humana de ese código puede llevar horas. Y si el sprint se planifica mirando solo la velocidad de generación —cuántas historias puede "escribir" la IA—, se crea un cuello de botella masivo en la revisión humana. El sprint se colapsa: todo el código está "generado", pero nadie ha podido revisarlo, integrarlo ni validarlo.

Este patrón encaja perfectamente con lo que Goldratt describía: cuando optimizas un componente que no es la restricción (en este caso, la velocidad de generación), no mejoras el sistema; lo empeoras, porque produces más inventario (código sin revisar) que se acumula antes del verdadero cuello de botella (la capacidad humana de verificación). Es como acelerar una línea de producción sin ampliar la estación de control de calidad: solo consigues una cola más larga de producto sin inspeccionar.

El informe Accelerate State of DevOps (DORA) de 2024, tras una década de investigación con más de 39.000 profesionales, ofrece un dato que ilumina esta dinámica: por segundo año consecutivo, la adopción de herramientas de IA correlaciona con un empeoramiento del rendimiento de entrega de software a nivel de equipo, aunque mejora la percepción de productividad individual. Es decir, cada persona siente que produce más, pero el equipo como sistema entrega igual o peor. Esto tiene todo el sentido si el cuello de botella ya no está en la producción individual sino en la integración, la revisión y la coordinación del sistema completo.

Qué significa esto dentro del sprint

Si aceptamos que la restricción se ha desplazado de "construir" a "revisar, integrar y validar", las implicaciones para el ciclo Scrum son concretas.

En la planificación del sprint, la decisión más importante ya no es cuántas historias caben en el sprint según la velocidad del equipo. La decisión crítica es la atribución humano/IA: qué trabajo requiere juicio humano, qué puede ejecutar un agente, y —esto es lo que la mayoría olvida— cuánto tiempo de revisión humana necesita cada tarea automatizada. La guía de Scrum Manager propone que las tareas R&I se estimen explícitamente y se incluyan en la planificación, precisamente para evitar el colapso del sprint. Si un equipo planifica diez historias porque la IA "puede generarlas todas", pero solo tiene capacidad para revisar cuatro, no tiene diez historias en el sprint: tiene cuatro, y seis unidades de inventario que generan ruido, deuda técnica y falsa sensación de avance.

En el scrum diario (o check-in diario, como evoluciona en contextos con IA), el foco se desplaza de "qué hice ayer / qué haré hoy" a la gestión de desviaciones: ¿los agentes IA están produciendo lo esperado? ¿Hay outputs que se desvían de la especificación? ¿Algún módulo generado presenta baja calidad que va a requerir más revisión de la prevista? La conversación ya no es sobre el progreso de la implementación —la IA se encarga de eso—, sino sobre la salud del flujo entre generación y validación.

En la revisión del sprint, el cambio es todavía más profundo. No basta con demostrar lo construido. Cuando la IA puede generar prácticamente cualquier cosa, la pregunta relevante deja de ser "¿hemos construido lo que planificamos?" y pasa a ser "¿hemos validado que lo construido resuelve el problema correcto?". El sprint review evoluciona de una demostración a una sesión de aprendizajes validados. Un prototipo rápido generado por IA que se descartó porque no superó la validación con usuarios es un resultado tan valioso como una funcionalidad terminada, si generó aprendizaje estratégico.

En la retrospectiva, aparece una nueva dimensión: la evaluación explícita de la colaboración humano-IA. ¿Le estamos dando buen contexto a la IA? ¿Revisamos con el rigor adecuado? ¿La Definition of Done reforzada está funcionando? ¿Estamos acumulando deuda técnica sin darnos cuenta? La guía de Scrum Manager señala que la retrospectiva es ahora más importante que nunca, porque los equipos están aprendiendo a trabajar con una tecnología nueva y necesitan un espacio deliberado para reflexionar sobre esa relación.

La deuda técnica invisible que genera la velocidad

Hay un cuello de botella que la IA no crea de forma inmediata, sino que siembra para el futuro: la deuda técnica acumulada por código generado.

La IA tiende a generar código nuevo en lugar de mejorar el existente. Cada vez que un agente produce un módulo, existe el riesgo de que duplique lógica ya presente en el sistema, introduzca patrones inconsistentes con la arquitectura, o genere soluciones que funcionan pero son frágiles. Si nadie revisa con profundidad —y ya hemos visto que la revisión es precisamente el cuello de botella—, esta deuda se acumula sprint tras sprint.

Ward Cunningham, quien acuñó el término "deuda técnica" en 1992, la comparó con un préstamo financiero: ganas velocidad ahora pero pagas intereses después. En el contexto de equipos con IA, esta metáfora adquiere una urgencia nueva. La IA permite contraer deuda técnica a una velocidad sin precedentes, porque puede generar cantidades enormes de código en muy poco tiempo. Si el equipo no tiene la capacidad de revisión para detectar y gestionar esa deuda, los intereses se acumulan de forma exponencial: velocidad decreciente sprint tras sprint, bugs crecientes, y un código base que cada vez cuesta más mantener y evolucionar.

La guía de Scrum Manager propone métricas específicas para detectar esta situación: el ratio de código refactorizado frente a código nuevo, la duplicación de código (indicador crítico en proyectos asistidos por IA), y el tiempo de revisión humana por tarea IA como indicador del cuello de botella real. La velocity clásica —puntos de historia por sprint— pierde relevancia cuando parte del trabajo lo ejecuta una máquina, porque no mide el valor entregado sino el volumen producido.

Cuando construir es fácil, decidir qué construir se convierte en el cuello de botella

Hay otro desplazamiento de la restricción que merece atención, quizá el más profundo de todos. Si la IA reduce drásticamente el coste de construir, la decisión de qué construir se vuelve proporcionalmente más importante —y más costosa si se equivoca—.

Hasta ahora, el coste de implementar una funcionalidad equivocada era alto pero acotado: varias semanas de desarrollo del equipo. Con la IA, construir la funcionalidad equivocada puede costar horas en lugar de semanas, pero el problema no está en el coste de construcción sino en el coste de oportunidad y en la deuda generada. Un equipo que puede construir diez cosas a la semana pero que no valida ninguna con usuarios reales genera diez funcionalidades potencialmente inútiles en lugar de una. La velocidad amplifica tanto los aciertos como los errores.

Marty Cagan lleva años argumentando que la diferencia entre los mejores equipos de producto y el resto no reside en la velocidad de entrega sino en la calidad del descubrimiento: la capacidad de identificar qué construir antes de invertir capacidad en construirlo. En un mundo donde la IA comprime los tiempos de construcción, esta tesis se vuelve más relevante, no menos. El cuello de botella se desplaza aguas arriba: del delivery al discovery.

La guía de Scrum Manager refleja esta idea cuando propone que el product backlog evolucione de una lista de features a un repositorio de hipótesis a validar, donde cada ítem debería poder responder "¿qué problema resuelve y para quién?". Y cuando propone medir no solo el volumen producido por sprint, sino las hipótesis validadas por sprint como indicador del valor estratégico entregado.

Esto conecta directamente con lo que el documento de historias de usuario de Scrum Manager advierte sobre los riesgos de la IA: se puede terminar con un backlog lleno de historias que suenan profesionales, siguen el formato correcto y cumplen con INVEST, pero que no resuelven problemas reales de los usuarios. La IA no comprende a tus usuarios, no conoce la estrategia de tu empresa ni las restricciones de tu contexto. Puede generar historias "técnicamente correctas pero estratégicamente irrelevantes". Si el equipo no tiene un mecanismo robusto de validación —contacto real con usuarios, experimentación, métricas de impacto—, la velocidad de la IA solo amplifica la irrelevancia.

La conversación como restricción que no puede automatizarse

El modelo de las tres Cs de Ron Jeffries —Card, Conversation, Confirmation— describe la esencia de las historias de usuario. La tarjeta es un recordatorio breve. La conversación es donde se construye el entendimiento compartido. La confirmación valida que se entendió correctamente.

La IA puede generar tarjetas impecables. Puede sugerir criterios de aceptación detallados. Puede incluso producir confirmaciones en forma de tests automatizados. Lo que no puede hacer es reemplazar la conversación. Y cuando genera historias tan pulidas que parecen no necesitar conversación, crea una trampa sutil: el equipo asume que la historia ya está "terminada" y procede a implementarla sin el diálogo que le da sentido.

En un equipo Scrum que trabaja con IA, esta trampa se manifiesta de forma concreta en la planificación del sprint. Si las historias llegan con redacción impecable y criterios de aceptación exhaustivos —todo generado por IA—, el equipo puede caer en lo que la guía de historias de usuario de Scrum Manager identifica como un riesgo de "inhibición de la conversación". El resultado paradójico es que la IA, al producir artefactos de apariencia profesional, puede erosionar precisamente la práctica que da vida al framework: la comunicación directa entre personas.

Esto introduce una restricción de naturaleza diferente a las anteriores. No es una restricción de capacidad (no hay suficientes personas para revisar) ni de proceso (el flujo está mal diseñado). Es una restricción cognitiva y cultural: la tendencia humana a confiar en lo que parece completo, amplificada por sesgos como el automation bias —la confianza excesiva en sistemas automatizados— y el authority bias —la tendencia a aceptar como válido lo que proviene de una fuente que parece autorizada—.

En AgiLevel, la herramienta de diagnóstico de agilidad organizativa de Scrum Manager, la IA se ubica como tecnología, no como miembro del equipo. La distinción es importante: en un entorno ágil, la tecnología potencia a las personas, pero son las personas quienes priorizan y deciden. Si la IA genera las historias, define los criterios y sugiere las prioridades, ¿quién lleva el volante? La agilidad no se otorga ni se deniega por usar IA, sino por quién conduce el ciclo iterativo de entrega de valor.

Cinco preguntas para encontrar tu cuello de botella actual

La Teoría de Restricciones nos enseña que el cuello de botella siempre existe. Eliminarlo no te libera de restricciones: hace que la restricción se desplace a otro punto. El trabajo del equipo no es eliminar todas las restricciones —eso es imposible—, sino desarrollar la capacidad de identificar la restricción actual y actuar sobre ella.

En un equipo Scrum que trabaja con IA, estas preguntas pueden ayudar a orientar la búsqueda:

¿Cuántas historias del último sprint se "generaron" pero no se revisaron a tiempo? Si la respuesta es más de cero, la restricción probablemente está en la capacidad de revisión humana, no en la capacidad de generación.

¿Cuánto tiempo del sprint se dedica a tareas R&I frente a tareas de generación? Si la proporción está desequilibrada a favor de la generación, el equipo está alimentando un cuello de botella que aún no ve.

¿Las historias que entran en el sprint han sido validadas con usuarios reales, o son hipótesis sin contrastar generadas por el product owner (o por la IA)? Si la validación no existe, el cuello de botella puede estar antes del sprint: en la ausencia de discovery.

¿El equipo tiene conversaciones reales sobre las historias, o las trata como documentos cerrados porque "ya vienen bien escritas"? Si la conversación ha desaparecido, el cuello de botella puede ser cultural: una sobreconfianza en los outputs de la IA.

¿La deuda técnica del proyecto está creciendo sprint tras sprint? Si la duplicación de código aumenta, la complejidad ciclomática crece y la cobertura de tests baja, el cuello de botella está en la calidad de la integración, y el equipo está hipotecando su velocidad futura por la velocidad presente.

No hay una respuesta universal. Cada equipo, cada producto y cada organización tiene su propia restricción. Lo importante no es encontrar "la" respuesta, sino hacerse las preguntas con honestidad y frecuencia. La restricción de hoy no será la de dentro de tres meses, especialmente en un momento donde la tecnología y las formas de trabajar evolucionan a esta velocidad.

La guía Scrum en equipos con IA de Scrum Manager profundiza en cómo evolucionan los roles, artefactos y eventos de Scrum cuando humanos y agentes de IA trabajan juntos. En el Club Agile encontrarás un espacio para compartir experiencias sobre cómo tu equipo está navegando esta transición. Y si te interesa diagnosticar cómo la dimensión organizativa de tu empresa condiciona la integración de la IA, los recursos de AgiLevel pueden ofrecer un punto de partida.

No hay respuesta correcta. Lo interesante es descubrir dónde siente cada equipo que se ha movido la restricción. Cuéntanos en los comentarios.

Bibliografía

Cagan, M. (2018). Inspired: How to Create Tech Products Customers Love (2ª edición). Wiley.

DeGrandis, D. (2017). Making Work Visible: Exposing Time Theft to Optimize Work & Flow. IT Revolution Press.

DORA Team (2024). Accelerate State of DevOps Report 2024.

Forsgren, N., Humble, J. y Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.

Goldratt, E. M.

• (1984). The Goal: A Process of Ongoing Improvement. North River Press.
• (1990). What Is This Thing Called Theory of Constraints and How Should It Be Implemented?. North River Press.

Jeffries, R., Anderson, A. y Hendrickson, C. (2001). Extreme Programming Installed. Addison-Wesley.

Kim, G., Behr, K. y Spafford, G. (2013). The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. IT Revolution Press.

Scrum Manager

• (2025). Historias de usuario. Disponible en recursos.
• (2026). Scrum en equipos con IA. Versión 1.0. Disponible en recursos.

Vacanti, D. S. (2015). Actionable Agile Metrics for Predictability: An Introduction. ActionableAgile Press.