Planificación y estimación de sprint en la era de la IA

Los equipos que adoptaron IA en el desarrollo suelen mantener la ceremonia de planificación exactamente igual y después se extrañan de que las estimaciones empeoraron. No es una impresión: la IA mueve justamente la variable que la estimación por analogía supone estable.

Por qué la estimación empeora antes de mejorar

Estimar por puntos funciona porque el equipo compara la tarea nueva con tareas parecidas ya entregadas. Eso presupone que el costo de una tarea de cierto tipo es razonablemente predecible.

La IA amplía la dispersión de ese costo. El mismo cubo de esfuerzo ahora cubre casos donde el asistente resuelve casi todo y casos donde estorba, y lo que decide no es la complejidad aparente: es qué tan nuevo es el código, cuánto contexto implícito existe y qué tan verificable es el resultado.

Resultado: el promedio puede mejorar, pero el rango queda tan ancho que el número pierde utilidad para comprometerse.

Estima el tipo de tarea, no solo el tamaño

Un ajuste barato y eficaz es agregar una dimensión a la conversación de planificación: además de "qué tan grande", preguntar "¿cuánto de esto es territorio conocido?".

Tres franjas alcanzan:

• Verde. Código nuevo, patrón común, resultado verificable por pruebas. Aquí la IA ayuda más y la estimación puede encoger con seguridad.
• Amarillo. Código existente con buena cobertura de pruebas. Ganancia moderada, estimación parecida a la histórica.
• Rojo. Código central, antiguo, con reglas de negocio implícitas y poca cobertura. Aquí la IA puede costar tiempo, y la estimación no debería encoger.

Esa clasificación toma un minuto por ítem y explica la mayor parte de la variación que hoy aparece como "erramos la estimación".

Scrum no pide puntos

Vale recordar qué exige realmente la Guía de Scrum de la planificación: establecer por qué el sprint es valioso, qué se puede entregar y cómo se hará el trabajo. No prescribe puntos de historia, ni velocity, ni planning poker.

Eso abre una decisión que muchos equipos posponen: cuando la previsibilidad del ítem cae, contar ítems pequeños suele pronosticar mejor que sumar puntos de ítems grandes. Rebanar más fino y medir el throughput es más robusto ante la variación que introdujo la IA.

Deja que la cadencia hable más fuerte que la estimación

El Manifiesto Ágil ya ponía el software funcionando por encima de la documentación y la respuesta al cambio por encima de seguir un plan. Las métricas de flujo están más alineadas con eso que la precisión de la estimación.

Las cuatro métricas de DORA siguen siendo el mejor conjunto pequeño para esto: lead time de cambios, frecuencia de despliegue, tasa de fallo en cambios y tiempo de restauración. Capturan si el equipo entrega con seguridad, que es la pregunta real detrás de "¿cupo el sprint?".

Un detalle importante al adoptar IA: léelas las cuatro juntas. Entregar más rápido con la tasa de fallo subiendo no es ganancia, es deuda transferida a quien está de guardia.

Dónde ayuda la IA en la ceremonia misma

Sin convertir la planificación en teatro de automatización, tres usos se pagan solos:

• Rebanado. Darle el ítem grande al modelo y pedirle tres descomposiciones verticales distintas, cada una entregando valor de punta a punta. Sirve como punto de partida, no como decisión.
• Levantamiento de riesgo. Pedir la lista de supuestos implícitos y casos borde del ítem. Bueno para salir del "parecía simple".
• Contexto de código. Preguntar qué archivos e integraciones probablemente toca el ítem, para clasificar verde, amarillo o rojo con más información.

Lo que no funciona es pedirle la estimación al modelo. No conoce tu deuda técnica, tu cola de review, ni quién está de vacaciones.

Cuida la carga cognitiva

El trabajo sobre experiencia de desarrollo propone mirar tres dimensiones: ciclos de feedback, carga cognitiva y estado de flujo. La IA mueve las tres, y no siempre a favor.

Revisar código que no escribiste tiene carga cognitiva alta. Un equipo que genera mucho más código del que antes revisaba lo siente primero como cansancio y después como caída de calidad. La planificación tiene que reservar capacidad de revisión, no solo capacidad de escritura.

Qué significa esto para tu equipo

Agrega la clasificación verde, amarillo y rojo al refinamiento durante tres sprints y compara el error de estimación por franja. Probablemente descubras que el problema estaba concentrado en el rojo.

Reserva capacidad explícita de revisión en el sprint, proporcional al volumen que la IA empezó a generar. Y sigue las cuatro métricas de DORA lado a lado, para no celebrar una velocidad que se está pagando en estabilidad.