Guía

Cómo hacer una revisión del sprint asíncrona

En una revisión del sprint asíncrona, el equipo publica demos grabadas cortas en lugar de presentar en una reunión. Los interesados las ven cuando les conviene y comentan antes de una fecha fija, y lo que dicen da forma al siguiente sprint. Esta guía explica cuándo hacerla, cómo grabar una demo que valga la pena ver, qué preguntar y cómo convertir las respuestas en tickets.

Actualizado el

Antes de empezar

Cuándo funciona una revisión del sprint asíncrona y cuándo conviene reunirse

En la revisión del sprint, las personas de fuera del equipo ven lo que se construyó y dicen qué debería cambiar. La versión asíncrona mantiene eso sin tener que encontrar un horario para todos. Sirve para la mayoría de los sprints, pero no para todos.

Hazla asíncrona si

  • Tus interesados no pueden coincidir en un horario

    Están en otras zonas horarias o tienen la agenda llena de llamadas con clientes. Así, cada uno ve las demos cuando le conviene.

  • El trabajo se puede mostrar en pantalla

    Una pantalla nueva, un flujo modificado, un reporte o la respuesta de una API. Si puedes mostrarlo funcionando, puedes grabarlo.

  • A la mayoría le importan uno o dos temas

    En una reunión, ventas tiene que aguantar la migración de la base de datos para ver la página de precios. Con una demo por tema, cada persona ve solo las que le importan.

  • Quieres los comentarios por escrito

    Un comentario en una grabación queda ligado a aquello de lo que habla y se puede vincular a un ticket. Lo que se dice en una reunión depende de las notas de alguien.

Hazla en vivo si

  • Una decisión necesita ir y venir

    Cambiar el alcance, las prioridades o el objetivo del producto requiere el tipo de conversación que un hilo de comentarios hace mal.

  • El sprint no cumplió su objetivo

    Cuando algo salió mal, la gente quiere hacer preguntas y escuchar las respuestas. Explícalo en vivo y deja las demos para el trabajo terminado.

  • Hay poco que ver

    Una migración de base de datos, una investigación técnica o un trabajo de infraestructura se explica mejor en una conversación que en una grabación.

  • Tus interesados son nuevos para el equipo

    Reúnete con ellos algunas veces primero, para que conozcan al equipo y el tipo de comentarios que ayudan. Después pasa las demos a formato asíncrono.

O haz las dos cosas: publica las demos de forma asíncrona y reserva 15 minutos en vivo para las decisiones. La reunión es corta, porque las demos y las primeras reacciones ocurren antes.

Paso a paso

Cómo hacer una revisión del sprint asíncrona en seis pasos

Empieza unos días antes de que termine el sprint, para tener los comentarios antes de planificar el siguiente.

  1. Paso 1

    Elige quién revisa cada parte del trabajo

    No todos necesitan verlo todo. Para cada función o corrección, elige a quienes la van a vender, darle soporte, diseñar en torno a ella o decidir sobre ella, y nombra a la persona sin cuya respuesta no puedes lanzarla. Una lista corta de las personas indicadas da más comentarios que una lista larga con todo el mundo.

    En Circlebak · Agrégalos como interesados de la demo. Los interesados de su colección también reciben un correo por cada demo nueva que se publica ahí, así que nadie tiene que acordarse de invitarlos.

  2. Paso 2

    Define una fecha límite para comentarios

    Sin una fecha, los comentarios asíncronos llegan a cuentagotas durante semanas o nunca llegan. Elige la fecha al publicar, ponla al principio de la descripción y respétala. A la mayoría de los equipos les sirven dos días hábiles: es tiempo suficiente para otras zonas horarias y semanas complicadas, y lo bastante corto para llegar antes de la planificación del sprint. Lo que llegue después va al backlog, como cualquier otra solicitud.

    En Circlebak · Define la fecha al subir el video. Un día antes, los interesados que todavía no comentaron reciben un recordatorio por correo, así no tienes que perseguirlos.

  3. Paso 3

    Graba una demo corta por cada parte del trabajo

    Graba cada función o corrección en su propia demo, de tres a cinco minutos, mostrando el producto real. Cada persona ve las partes que le interesan y tú recibes comentarios sobre cada parte por separado. Si una demo pasa de cinco minutos, casi siempre son dos demos. En Cómo grabar una buena demo están la estructura y los consejos.

    En Circlebak · Circlebak no graba. Usa el grabador que ya tienes y sube el archivo en MP4, MOV, WebM o MKV, de hasta 5 GB.

  4. Paso 4

    Publícala con preguntas concretas

    “¿Algún comentario?” recibe silencio o detalles sin importancia. Ponle a la demo un título que diga qué cambió y luego escribe el objetivo, qué está listo y qué no, y dos o tres preguntas que solo tus interesados pueden responder. Pídeles a los revisores que comenten en el momento exacto al que se refieren, así “esto es confuso” señala justo lo que confunde.

    En Circlebak · Los comentarios quedan fijados en el segundo del que hablan. Menciona con @ a la persona cuya respuesta necesitas y le llegará un correo.

  5. Paso 5

    Responde y convierte los comentarios en tickets

    Responde cada comentario, aunque sea solo para decir que lo viste, así los revisores saben que valió la pena. Luego clasifica cada uno: se cambia en este sprint, se crea un ticket para más adelante o se deja como está, y explica por qué. Para todo lo que se convierta en trabajo, crea el ticket en tu herramienta de seguimiento y vincúlalo desde el comentario, para que quien lo planteó pueda seguirlo ahí. Marca el hilo como resuelto cuando esté atendido.

    En Circlebak · Pega el enlace del ticket en el comentario. Circlebak reconoce Jira, Linear, GitHub, GitLab, Azure DevOps y Asana, y cualquier otro enlace también funciona. No se sincroniza nada, así que no hay nada que instalar.

  6. Paso 6

    Cierra el ciclo

    Cuando pase la fecha límite, cuéntales a todos los que participaron qué escuchaste, qué cambia y qué se convirtió en ticket. Lleva las preguntas abiertas a la planificación del sprint, o a una reunión corta en vivo si necesitan una decisión. Los interesados que ven que sus comentarios sirven siguen dándolos.

    En Circlebak · Los hilos resueltos muestran lo que ya se atendió, y cada comentario vinculado lleva a su ticket.

Grabación

Cómo grabar una buena demo de 3 a 5 minutos

Una demo no es una presentación. Muestra el producto funcionando, di por qué importa y termina con lo que necesitas de quienes la ven.

Una demo de cuatro minutos y medio, parte por parte
  1. 0:00

    El objetivo

    Una oración sobre el problema que resuelve y para quién.

  2. 0:30

    Muéstralo funcionando

    Recorre el flujo real con datos realistas, como lo usaría un cliente.

  3. 3:30

    Lo que falta

    Di qué falta, qué está simulado o qué todavía puede cambiar, para que nadie gaste un comentario en eso.

  4. 4:00

    Tus preguntas

    Haz las dos o tres preguntas que necesitas que te respondan y di para cuándo.

  • Cierra lo que no es parte de la demo

    Activa No molestar, cierra otras pestañas y ventanas, y usa datos realistas en lugar de “prueba 123”.

  • Haz que el texto se lea bien

    Graba una sola ventana en lugar de una pantalla grande y sube el zoom del navegador a 125 % o más, para que se pueda leer en una laptop.

  • Cuéntalo, no leas un guion

    Di qué haces y por qué, como se lo contarías a un colega que está a tu lado. Con unas pocas notas basta.

  • Cuida el sonido

    Un mal sonido cuesta más de aguantar que una imagen imperfecta. Con una habitación silenciosa y unos auriculares con micrófono basta.

  • Muestra qué pasa cuando algo falla

    Un error, una lista vacía o un permiso que falta. Ventas y soporte van a preguntar por esto, así que muéstralo antes.

  • No pierdas tiempo editando

    Una toma con un pequeño tropiezo está bien. Si te pierdes, haz una pausa y sigue, o vuelve a grabar esa parte.

Plantilla

Plantilla para la revisión del sprint asíncrona

Cópialas en la descripción de tu demo, en tu herramienta de seguimiento o donde publiques. Reemplaza lo que está entre corchetes y deja solo las preguntas que apliquen.

La publicación de la demo

El título y la descripción que los revisores leen antes de reproducirla.

[Qué cambió, en pocas palabras]

Objetivo: [el problema que resuelve y para quién]

En esta demo
- [Qué muestras y dónde empieza, por ejemplo 0:30]
- Listo: [lo que ya funciona]
- Pendiente: [lo que falta, está simulado o todavía puede cambiar]

Preguntas para ustedes
1. [Una pregunta que solo los interesados pueden responder]
2. [Una decisión que necesitas que tomen]

Comentarios hasta el [día y fecha]. Lo que llegue después va al backlog.
Tickets: [enlace a la épica o a los tickets]

Preguntas para los revisores

Elige dos o tres para cada demo. Las preguntas concretas reciben respuestas concretas.

¿Esto resuelve el problema que debía resolver? Si no, ¿qué falta?
¿Qué te impediría vender, dar soporte o usar esto el día del lanzamiento?
¿Qué esperabas ver que no está aquí?
¿Hay algo tan confuso que un cliente preguntaría por ello?
¿Qué opción deberíamos lanzar, A o B, y por qué?
¿Quién más debería ver esto antes del lanzamiento?

Un mensaje para la primera revisión asíncrona

Envíaselo a tus interesados antes de la primera, para que sepan qué esperar.

La revisión de este sprint es asíncrona. En lugar de la reunión, cada equipo va a publicar una demo corta de lo que construyó, de 3 a 5 minutos cada una, a más tardar el [día].

Mira las que te interesen, cuando te convenga, y comenta en el momento exacto al que te refieres. Cada demo termina con las preguntas que necesitamos que respondas.

Deja tus comentarios a más tardar el [día y fecha]. Vamos a responder cada comentario y a contarte qué cambia gracias a ellos.

Lista de verificación

Lista de verificación para la revisión del sprint asíncrona

Repásala en cada sprint hasta que se vuelva un hábito.

Antes de que termine el sprint

  • Revisores elegidos para cada parte del trabajo, con una persona que debe responder
  • Una fecha límite unos dos días hábiles después de publicar
  • Una reunión corta en vivo agendada, solo si una decisión la necesita

Grabación

  • Una demo por función o corrección, de 3 a 5 minutos cada una
  • Notificaciones desactivadas, otras pestañas cerradas y texto que se lee bien
  • El objetivo en los primeros 30 segundos
  • Lo pendiente, dicho, y tus preguntas al final

Publicación

  • Un título que dice qué cambió
  • Una descripción que sigue la plantilla, con las preguntas y la fecha límite
  • Interesados avisados de dónde ver la demo y para cuándo

Mientras llegan los comentarios

  • Una respuesta a cada comentario
  • Un ticket vinculado para todo lo que se convierta en trabajo
  • Hilos marcados como resueltos una vez atendidos

Después de la fecha límite

  • Un resumen compartido: qué escuchaste, qué cambia y qué se convirtió en ticket
  • Preguntas abiertas llevadas a la planificación del sprint

Cópiala como lista de tareas para pegarla en tu herramienta de seguimiento o en tus notas.

Con Circlebak

Haz tu revisión del sprint asíncrona en Circlebak

Circlebak está hecho para esto. Los equipos suben sus demos y los interesados reciben un correo. Los comentarios quedan fijados en el momento exacto y vinculados a tickets, y los recordatorios salen antes de la fecha límite. Los revisores siempre son gratis.

Circlebak en 90 segundos

Leer la transcripción

Tu equipo de ingeniería pasó todo el sprint construyendo algo nuevo.

Así que agendas una demo… y de repente, todos están demasiado ocupados para ir.

¿Plan B? Meter a todo el departamento en una sola demo de tres horas.

Pero nadie aguanta tres horas por la única función que le interesa. Así que las personas que necesitas… no llegan.

¿Y la grabación? Suerte encontrando su parte.

Así que sale sin sus comentarios. No es lo que nadie esperaba. Ahora pagas por rehacerlo, y tus clientes lo notaron.

Ahí es donde entra Circlebak.

Olvídate de la reunión gigante. Cada equipo graba un video corto de su trabajo y lo publica.

Etiqueta a los interesados que importan. Reciben un aviso al instante y un recordatorio antes de que cierre el plazo para comentar.

Lo ven cuando les conviene y comentan justo en el momento que importa.

Vincula cualquier comentario a su ticket de Jira, Linear o GitHub, y síguelo hasta que esté terminado.

Así los problemas se detectan antes del lanzamiento, no después. Menos retrabajo. Sin llamadas incómodas con clientes.

Y puedes empezar gratis. Solo pagas por las personas que suben videos, desde 12 dólares al mes cada una. ¿Revisores? Siempre gratis.

Circlebak. Muestra el trabajo antes de lanzarlo.

Empezar gratis

Gratis para un creador. Los revisores siempre son gratis. 14 días de Business sin tarjeta.

Preguntas

Preguntas sobre las revisiones del sprint asíncronas

¿Cuánto debe durar una demo asíncrona del sprint?

De tres a cinco minutos por cada parte del trabajo: lo suficiente para mostrar el flujo de principio a fin y lo bastante corto para que la gente la vea completa. Si una dura más, divídela en dos demos.

¿Cuánto tiempo deben tener los interesados para comentar?

A la mayoría de los equipos les sirven dos días hábiles. Da al menos un día hábil completo en cada zona horaria con la que trabajas, y cierra antes de la planificación del sprint para que los comentarios puedan influir en el siguiente.

¿Quién debería ver las demos del sprint?

Cualquiera que vaya a vender, dar soporte, diseñar en torno al trabajo o decidir sobre él: producto, diseño, ventas, soporte, éxito del cliente y dirección. Elígelos para cada parte del trabajo, no para todo el sprint, así cada persona ve lo que le importa.

¿Qué pasa si los interesados no ven las demos?

Facilítales decir que sí: demos cortas, una por tema, una pregunta clara para cada persona y una fecha. Menciona a la persona cuya respuesta necesitas. Si alguien nunca las ve, pregúntate si de verdad necesita revisar ese trabajo.

¿Una revisión del sprint asíncrona sigue siendo una revisión del sprint de Scrum?

Puede serlo. La Guía de Scrum describe la revisión del sprint como una sesión de trabajo en la que los interesados inspeccionan el trabajo y el equipo adapta lo que viene después. Eso sigue ocurriendo si los interesados responden y el plan cambia por lo que dicen. Los equipos que necesitan hablar del objetivo del producto o del backlog suelen sumar una reunión corta en vivo para eso.

¿Cuál es la diferencia entre la revisión del sprint y la retrospectiva?

La revisión trata sobre el producto: qué se construyó y qué debería cambiar. La retrospectiva trata sobre el equipo: cómo trabajaron juntos y qué hacer distinto. Esta guía trata sobre la revisión.

Muestra tu próxima demo a quienes necesitan verla

Prueba todas las funciones de Circlebak gratis durante 14 días y después quédate con el plan Gratis o elige el que mejor te quede. Los revisores siempre son gratis.