Publicaciones

Cómo es una sprint review nativa de IA en 2026

La mayoría de los equipos con los que hablo siguen haciendo sprint reviews como si fuera 2018. Alguien comparte pantalla, repasa los tickets terminados, pregunta "¿alguna duda?" y la reunión termina. Los stakeholders asienten, nada cambia y la mitad deja de asistir para el cuarto sprint. Ese formato tenía sentido cuando entregar era lento y la gente tenía que estar en una sala para ver el trabajo. Ninguna de esas dos cosas sigue siendo cierta. Los equipos que usan herramientas de codificación con IA entregan el doble por sprint, y los stakeholders están repartidos entre zonas horarias y canales de Slack. La demo en vivo de 60 minutos no encaja con ninguna de esas dos realidades. Así es una sprint review en los equipos que la han reconstruido en torno a la IA.

El formato se ha invertido

El formato antiguo: 60 minutos en vivo, cargado de demos, baja participación. El nuevo formato: la mayor parte de la review ocurre de forma asíncrona antes de la reunión. La reunión en sí se reduce a 30 minutos y se convierte en una sesión de decisiones, no en una demo.

Fase	Formato antiguo	Formato nativo de IA
Antes de la reunión	Nada	Demos asíncronas, resumen de cambios generado por IA, briefing a stakeholders
Reunión	60 min de recorrido + Q&A	30 min discutiendo el material visto antes, decisiones sobre el próximo sprint
Después de la reunión	Notas perdidas en el Notion de alguien	La IA sintetiza el feedback en candidatos para el backlog
Carga sobre los stakeholders	Sentarse a ver todas las demos, relevantes o no	Ver solo las demos que les afectan, comentar a su propio ritmo

La ventaja es que los stakeholders dejan de tener que elegir entre "asistir a todo" y "perdérselo todo". Ven lo que les es relevante, en su tiempo, y llegan a la reunión en vivo ya con opinión formada.

Qué hace realmente la IA

Hay mucho humo alrededor de las "sprint reviews potenciadas por IA". Casi todo son dashboards con un chatbot pegado por encima. Si quitas esa capa, hay cuatro tareas que la IA hace bien ahora mismo.

Generar el resumen de cambios

El product owner solía dedicar una hora el día antes de la review a juntar "lo que entregamos este sprint". Ahora ese resumen se escribe solo. La IA lee los tickets cerrados, las descripciones de PRs y las release notes, y luego redacta un resumen legible para stakeholders agrupado por tema (no por ticket). El PO lo edita en lugar de escribirlo. Veinte minutos en vez de una hora, y el resultado es mejor porque está agrupado por lo que les importa a los stakeholders, no por orden de ticket.

Grabar e indexar demos

Los ingenieros graban demos de 2-3 minutos al estilo Loom de las funciones que han construido. La IA las transcribe, las etiqueta por área del producto y las enlaza con la historia original. Los stakeholders que las ven en asíncrono pueden buscar dentro de las demos ("muéstrame todo lo relacionado con checkout") en vez de adelantar y rebobinar una grabación de Zoom de 60 minutos.

Sintetizar el feedback en tiempo real

Esto es lo que me cambió la opinión sobre las reviews async-first. Durante la discusión en vivo, la IA escucha (con permiso) y agrupa los comentarios por tema según van llegando. Al final de la reunión no necesitas a nadie tomando notas. Tienes una lista clusterizada de preocupaciones de stakeholders, ya agrupadas, lista para convertirse en candidatos del backlog. Para los equipos que hacen su retro justo después de la review, la misma capa de IA que potencia el agrupado automático de retros se encarga del feedback de la review. Mismo patrón, ceremonia distinta.

Conectar el feedback con la historia

Mi uso favorito es el más simple: la memoria. "¿No habíamos hablado de esto hace dos sprints?" antes necesitaba a alguien con buena memoria y mucha paciencia para hacer scroll. Ahora la IA lo saca a flote: "El stakeholder mencionó esta preocupación en la review del 14 de marzo. El equipo se comprometió a revisarlo. Estado: aún abierto". Los stakeholders confían más en el proceso cuando ven que su aportación queda registrada, incluso tres sprints después. Es un detalle pequeño que cunde mucho.

Lo que sigue siendo obstinadamente humano

Algunas tareas de la sprint review parecen automatizables, pero no lo son. No malgastes esfuerzo intentándolo. Decidir qué mostrar. La IA puede listarte todas las historias cerradas. No puede decirte cuáles tres importan al VP de Ventas que tiene 20 minutos. Eso es una decisión sobre la audiencia, y un PO que conoce a sus stakeholders siempre lo hará mejor que un modelo. Leer la sala. Cuando un stakeholder dice "tiene buena pinta" con los brazos cruzados, el significado está en el lenguaje corporal. El análisis de sentimiento por IA sobre transcripciones se lo pierde por completo. Las reviews necesitan al menos a una persona humana atenta al desacuerdo que nadie dice en voz alta. Aceptar o rechazar feedback. Esta regla ya existía antes de la IA y sigue siendo válida. El PO recoge el feedback y luego lo evalúa en el refinamiento de backlog. No dejes que una herramienta de IA que crea tickets automáticamente a partir de los comentarios te empuje a comprometerte en el momento. La conversación de "¿deberíamos construir esto?". La IA te dice qué construiste. La pregunta más difícil en una sprint review es si el equipo está construyendo lo correcto. Esa es una conversación de estrategia entre personas, informada por los datos que la IA pone sobre la mesa, pero no decidida por ella.

Recorrido por una review nativa de IA

Este es el ritmo que usa un equipo con el que trabajo para un sprint de dos semanas. No es el único formato posible, pero muestra cómo encajan las piezas.

1. Dos días antes: los ingenieros graban demos

   Cada ingeniero graba un recorrido de 2-3 minutos de lo que ha construido. La IA las transcribe y las etiqueta. Esfuerzo total del equipo: quizá 30 minutos entre todos.

2. Un día antes: el PO envía el briefing

   La IA genera un borrador del resumen de cambios agrupado por tema. El PO lo edita, añade contexto de negocio para cada grupo y envía un único Loom más un enlace a la biblioteca de demos. Los stakeholders tienen 24 horas.

3. Ventana de feedback asíncrono

   Los stakeholders ven las demos que les afectan y dejan comentarios con marca de tiempo. La IA agrupa los comentarios por tema según van llegando, así el PO entra a la reunión sabiendo cuáles son los tres puntos principales a discutir.

4. Reunión en vivo, 30 minutos

   Sin compartir pantalla. Se abre con un "tú dijiste, nosotros hicimos" de la review anterior. Se discuten los clusters principales del feedback asíncrono. Se decide qué cambia en el próximo sprint. Fin.

5. Después de la reunión: la IA sintetiza al backlog

   La IA convierte los clusters de feedback en candidatos del backlog con contexto completo (qué stakeholder, qué demo, qué dijo). El PO los refina en su tiempo. Nada se cae entre las grietas.

El equipo que hace esto me contó que la asistencia a su review pasó de "tres de siete stakeholders, normalmente tarde" a "seis de siete, preparados, con feedback concreto". Lo que lo desbloqueó no fue la IA. Fue respetar el tiempo de los stakeholders lo suficiente como para no obligarles a tragarse demos que no les importaban.

Dónde se tuerce esto

Algunos patrones que he visto matar las reviews nativas de IA antes de que cojan tracción. Tratar lo asíncrono como "saltarse la reunión". El trabajo previo asíncrono reemplaza la demo, no la discusión. Los equipos que se cargan la reunión en vivo del todo pierden el momento de toma de decisiones y acaban con feedback de stakeholders que nunca se resuelve. Dejar que la IA escriba el briefing sin editarlo. Los resúmenes generados automáticamente llegan al 80%. El trabajo del PO es ese último 20%, que es el contexto de negocio y el encuadre de a qué deberían prestar atención los stakeholders. Si te lo saltas, el resumen suena a release note. Grabar demos que nadie ve. Si tus stakeholders no están viendo las demos asíncronas, lo más probable es que estés grabando demasiadas o que sean demasiado largas. Tres demos de 2 minutos le ganan a un recorrido de 15 minutos siempre.

Sprint review vs. retrospectiva en un equipo nativo de IA

Estas dos ceremonias siguen sirviendo a propósitos distintos, pero sus capas de IA se solapan más de lo que cabría esperar.

	Sprint review	Retrospectiva
Audiencia	Equipo + stakeholders	Solo el equipo
Trabajo principal de la IA	Sintetizar feedback externo en backlog	Agrupar feedback del equipo, seguir action items
Qué se automatiza	Resumen de cambios, clustering de feedback	Agrupado automático por similitud, sentimiento, resúmenes
Qué es humano	Estrategia y priorización	Reflexión honesta y seguridad psicológica

Si ya estás haciendo retrospectivas con agrupado y resúmenes por IA, ya tienes el 70% del camino para hacer una sprint review nativa de IA. Los patrones se trasladan. El cambio mayor es el cultural, pasar a async-first, no la herramienta.

Por dónde empezar

No necesitas una plataforma nueva. Coge la parte de tu review actual que más duele y aplícale IA.

• Si escribir el resumen de cambios le destroza el jueves a tu PO: empieza por los resúmenes generados automáticamente.
• Si las demos se alargan y los stakeholders desconectan: empieza por demos asíncronas pregrabadas.
• Si el feedback se pierde entre reviews: empieza por el clustering de feedback y el seguimiento.
• Si los stakeholders no aparecen: empieza por la apertura "tú dijiste, nosotros hicimos" en cada review.

Las mejores sprint reviews que he visto este año no son las que tienen la IA más sofisticada. Son aquellas en las que la IA quitó las partes que a nadie le gustaban, el recap y la toma de notas, para que la conversación de estrategia tuviera más oxígeno.