De horas a minutos: Cómo automaticé el cierre de Sprints con IA y n8n

Durante mucho tiempo, cada cierre de sprint significaba bloquear el viernes completo en el calendario para convertirme en recolector de métricas, y lo digo sin ninguna elegancia porque no la tenía: revisar y consolidar tickets de Jira, sacar los logs de las herramientas de CI/CD, contar los incidentes que habían llegado a producción, revisar uno por uno los Pull Requests, y recién con todo eso encima sentarme a escribir un resumen coherente para el pase a producción y a generar los tickets de cambios.

Tres horas, más o menos. Cada dos semanas. Durante meses.

Y lo peor no era el tiempo. Era darme cuenta, más o menos al segundo o tercer ciclo, de que nada de lo que estaba haciendo ahí requería que lo hiciera yo. Copiar un número de una pestaña a otra no es liderar, es transcribir.

”Lo hago yo porque nadie más sabe dónde está la información”

Esa era mi excusa y la creí bastante tiempo, si bien en el fondo sabía que no se sostenía. Nadie más sabía dónde estaba la información porque yo nunca había hecho el trabajo de dejarla en un solo lugar.

Así que armé el flujo. Con n8n me conecté a las herramientas internas para extraer la data cruda del sprint, y ese volumen se va hacia un LLM por API, contextualizado para procesarlo, detectar desviaciones de lo planeado y resumir el progreso del equipo.

El resultado es un dashboard que se genera solo en unos cinco minutos, con la salud general del sprint, las tendencias de entrega, los cuellos de botella y la velocity, y alertas de riesgo para anticipar incidentes en producción.

Ahora sí, manos a la obra, dije yo. Y ahí vino la parte que no esperaba.

Lo que de verdad cambió, y que no era el tiempo

Confieso que lo abordé como una victoria personal. Genial, recuperé tres horas de mi viernes, pensé, y me quedé bastante contento conmigo mismo.

La sorpresa llegó por el lado, un par de ciclos después. Al estar el flujo automatizado y a la vista de todos, el equipo dejó de depender de mí para saber cómo iba el ciclo. Empezaron a revisar el dashboard por su cuenta, a notar los gaps de información en QA antes de que fueran un problema, y a corregir tickets mal cerrados sin esperar mi auditoría de los viernes.

Yo había construido una herramienta para ahorrarme trabajo y terminé construyendo una que le quitó un intermediario al equipo. Ese intermediario era yo.

Esa es la lección que me llevo, y me costó un par de sprints entenderla: la mejor herramienta no es la que te hace más rápido, es la que hace que tu equipo no te necesite para saber cómo van las cosas.

Tres cosas que aprendí en el camino

”Encontré una herramienta increíble, ahora busco dónde usarla”

Es tentador dejarse arrastrar por el hype, y yo también he empezado proyectos por ese lado. Pero si el proceso que intentas automatizar no era un suplicio real y constante para alguien, nadie va a usar lo que construyas, y vas a terminar con una herramienta impecable que abre una sola persona, que además eres tú.

Empieza por el dolor crónico, ese del que todos se quejan siempre.

”La IA lo genera, así que lo mando directo”

No. El sistema compila y analiza bien, pero no tiene el contexto de lo que pasó esa semana en particular, no sabe que el equipo estuvo a medias porque hubo una caída el martes, y no conoce la cultura interna de cómo se comunican las cosas acá.

Siempre lo reviso yo antes de que llegue a alguien más. Confía, pero verifica, que en ciberseguridad se dice hace décadas y acá aplica igual.

”Ya lo automatizo y de paso ordeno el proceso”

Al revés, y este me costó entenderlo. Si tu proceso actual es un caos, aplicarle IA multiplica el caos: si las convenciones en Jira no se respetan y los commits no tienen consistencia, lo que te va a devolver es ruido bien redactado, que es peor que el ruido a secas porque parece un informe.

Primero ordenas y estabilizas. Después automatizas. En ese orden, aunque el primer paso sea el aburrido.

Por dónde empezar

Toma el proceso que más te pesa del mes y cronométralo una vez, de verdad, con reloj. Ese número solo ya te va a decir si vale la pena.

Después pregúntate cuánto de esas horas es criterio tuyo y cuánto es transcribir de una pestaña a otra. La segunda parte es la que se automatiza, y en mi caso era casi toda.