Si la IA programa en horas, ¿para qué un Sprint de dos semanas?
La pregunta ya anda rondando en LinkedIn, en foros y, sospecho, en más de una Daily. Y tiene su lógica. Si un agente de IA entrega en una tarde lo que antes le tomaba una semana al equipo, el Sprint de dos semanas empieza a verse como un trámite de otra época.
Confieso que la primera vez que me la planteé no tuve una respuesta rápida. Así que hice lo de siempre: volver a las guías. PMBOK 8, el estándar de IA del PMI, PM4R. Lo que encontré me sorprendió un poco. Ninguna dice «elimina el Sprint», pero tampoco lo defienden por las razones que solemos dar.
Antes de seguir, un detalle que casi nadie menciona en esta discusión: las dos semanas ni siquiera vienen de la Guía de Scrum, que solo pide Sprints de duración fija de un mes o menos. Las dos semanas son costumbre nuestra. Buena parte del debate defiende un número que nadie escribió.
LO QUE DICEN LAS GUÍAS SOBRE LA CADENCIA
≤ 1 mes
Duración máxima del Sprint según la Guía de Scrum
1 a 4 sem.
Iteraciones en PMBOK 8, que también acepta flujo y entrega continua
Híbrido
Iteraciones cortas con hitos largos: Estándar de IA del PMI, 4.1
HITL
Una persona en el proceso validando lo que produce la IA
El Sprint nunca fue un cronómetro de código
El PMBOK 8 lo dice sin rodeos. Los periodos de tiempo preestablecidos existen porque «ayudan a minimizar la corrupción o deslizamiento del alcance, ya que obliga al equipo a procesar primero las características esenciales» (Guía, Sección 4). El timebox es una herramienta para priorizar. Nadie lo inventó para medir cuánto tarda alguien en escribir una función.
La Guía Práctica PM4R Agile va por el mismo lado. Habla de «ciclos de ejecución y retroalimentación cortos» y de «aprender a través del descubrimiento». El ciclo está ahí para aprender.
Si la IA acelera la construcción, lo que cambia es dónde se atora el trabajo. Antes el freno era desarrollar. Ahora es validar lo que salió, decidir si sirve y lograr que el cliente lo absorba. Eso no pasa en horas.
El PMI ya abrió la puerta, con matices
El estándar de IA del PMI, en su sección 4.1, plantea un modelo híbrido para las iniciativas de IA: que puedan explorar «sin estar limitadas por plazos rígidos de sprint», combinando «iteraciones adaptativas a corto plazo con hitos a más largo plazo».
El propio PMBOK 8 reconoce que no todo tiene que vivir en iteraciones de 1 a 4 semanas. Incluye la planificación basada en el flujo (Kanban, teoría de restricciones) y acepta la entrega continua como una cadencia válida (Estándar, Sección 4).
Mi lectura es que el Sprint de dos semanas nunca fue sagrado. Pero cambiarlo porque «la IA va rápido» es decidir por la razón equivocada.
La pregunta útil es a qué ritmo puede aprender tu equipo, y a qué ritmo tu cliente puede darte retroalimentación que sirva.
Los tres pilares de Scrum, ahora con más trabajo
Donde sí veo un cambio de fondo es en los pilares del empirismo: transparencia, inspección y adaptación. Con IA en el equipo, pesan más que antes.
01 · TRANSPARENCIA
Un tablero visible ya no alcanza. El estándar de IA pide comunicación abierta sobre los riesgos de la IA y dice que «la explicabilidad es particularmente importante» (3.3.6.4). Llevado a la Sprint Review: alguien tiene que poder explicar qué hizo la IA y por qué confiamos en el resultado.
02 · INSPECCIÓN
Esta es la que más me inquieta. El PMBOK 8 (Apéndice X3) menciona que la IA puede detectar riesgo de retraso incluso cuando el burndown «parece estar progresando según lo planeado». Visto al revés, un burndown bonito ya no garantiza nada. Por eso el estándar insiste en mantener a una persona en el proceso (human in the loop, HITL) validando lo que produce la IA, y el PMBOK recuerda que el impacto de la IA «depende de… la supervisión humana».
Desde la PMO: si el burndown dejó de ser una señal confiable, toca revisar qué le estamos pidiendo al reporte de avance.
03 · ADAPTACIÓN
El estándar propone integrar la gobernanza de la IA «en los ciclos existentes… como las retrospectivas» (2.3.6.2) y reevaluar periódicamente el equilibrio entre IA e inteligencia humana (4.10.1). La Retrospectiva, lejos de sobrar, se convierte en el espacio donde el equipo decide cuánto le delega a la máquina.
¿Y el líder?
Hay una frase del estándar de IA que pegaría en la pared de varias oficinas: los equipos deben sentirse «empoderados para hablar cuando las salidas parezcan incorrectas», sin sanción por hacerlo (2.3.6.1).
La Guía de Liderazgo de PM4R lo baja a conductas concretas: dar márgenes de seguridad para ensayar nuevas formas de trabajo, reconocer errores, dar y recibir feedback de forma constante.
Si tu equipo no se atreve a decir «esto que generó la IA está mal», da igual que el Sprint dure dos semanas o dos días.
MI POSTURA, POR AHORA
No tengo una respuesta cerrada, y desconfío un poco de quien diga tenerla. Lo que sí veo, con las guías en la mano, es que la IA puede volver obsoleta la manera en que muchos equipos usan el Sprint: como un contenedor para «terminar tareas». La razón de fondo sigue ahí. Necesitamos un ritmo para inspeccionar, aprender y corregir.
Tal vez tu Sprint deba durar una semana. Tal vez te convenga pasar a flujo continuo con hitos trimestrales, como sugiere el modelo híbrido del PMI. Lo que no haría es decidirlo mirando la velocidad del código.
Te dejo la pregunta: en tu equipo, ¿cuál se volvió el verdadero cuello de botella desde que llegó la IA?
FUENTES
- PMI. Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK®), 8.ª ed. Estándar, Sección 4; Guía, Sección 4; Apéndice X3. pmi.org
- PMI. El Estándar para la Inteligencia Artificial en la Dirección de Portafolios, Programas y Proyectos. Secciones 2.2, 2.3.6, 3.3.6.4, 4.1 y 4.10.1. pmi.org
- Schwaber, K. y Sutherland, J. La Guía de Scrum, 2020. scrumguides.org
- BID / PM4R. Guía Práctica PM4R Agile, 3.ª ed.
- BID / PM4R. Guía de Liderazgo, 1.ª ed., Módulo 3.
¡SE ACTUALIZA DÍA CON DÍA!
Consulta nuestro Glosario de Términos Project Management
Ir al Glosario →Síguenos en las Redes Sociales
Nos leemos pronto, ¡un abrazo!
