Artículo original: How to Run a Great Sprint Review – Actionable Tips for Developers and Teams
En mis veinte años de experiencia como ingeniero de software, he estado en muchas revisiones de sprint. Las he visto hacer bien y he visto que a veces se las usa para que las personas hagan un alto en una sala de reuniones por un par de horas cada sprint.
Realizada de manera correcta, la revisión de sprint puede ser la clave para mantener al día tu proyecto. Por el contrario, las revisiones de sprint hechas de forma incorrecta son peor que el tiempo malgastado en ellas, ya que disminuyen la confianza de las personas en la metodología Scrum.
En este artículo, te voy a guiar a través de algunas ideas y el paso a paso para hacer que tu revisión de sprint tenga más valor.
¿Qué es una revisión de sprint?
Una revisión de sprint es una sesión corta que se realiza al final de cada sprint, usualmente cada un par de semanas.
Esta sesión permite al equipo mostrar el trabajo realizado a través de demos, obtener feedback y decidir qué es lo que sigue.
Al hacerse de forma correcta, la revisión de sprint muestra progreso y crea confianza a las personas que tienen un interés en el producto y el proyecto.
Por supuesto, es posible decirles a los interesados que el proyecto está al día, pero si pueden verlo con sus propios ojos durante la revisión de sprint, estarán más contentos.
¿Quién debería estar en la revisión?
En resumen, cualquier persona que así lo quiera. Cualquier persona que sea parte interesada en cualquier capacidad puede y debería estar presente en estas reuniones.
El propio equipo scrum se encuentra en el centro de la reunión, pero también pueden estar los de Ventas, los subgerentes generales, otros equipos scrums y project managers.
Si alguien tiene algo para aportar al proyecto o cree que puede beneficiarse por aprender algo del proyecto, deberían asistir,
¿Qué hacer antes de la revisión de sprint?
Para que la reunión se lleve a cabo sin ningún problema, es necesario asegurarse que quienes vayan a presentar estén preparados y con una demo lista para mostrar.
Por experiencia propia, las demos en vivo no funcionan. Algunas sí, pero en su mayoría no.
Puedes decirles a quienes tengan una demo que al menos se graben mostrando el flujo de trabajo antes de la reunión. De esta manera, si insisten en hacer una demo en vivo, van a tener un video grabado a modo de resguardo si todo sale mal.
También deberías tener una lista con las personas que van a presentar y en qué orden. Agrúpalas por similitud del tema. No importa quién presenta y cuándo lo hace mientras que las presentaciones estén agrupadas por tema.
Por ejemplo, si tienes seis ingenieros - dos trabajando en una página de inicio de sesión, dos más trabajando en servicio back-end nuevo y otros dos trabajando en la performance de la base de datos- asegúrate que en tu lista de presentadores estas tres areas distintivas estén juntas.
Si hay dos demos que son similares, puedes explicar el contexto una sola vez y después correr las demos una seguida de la otra. Se eficiente, ya que tienes a muchas personas en esta reunión y todos saben que las reuniones son costosas.
Durante la revisión
Los ingenieros de software que hayan trabajado en alguna parte del proyecto harán la presentación a los otros miembros del equipo scrum (Producto, QA y otros) y también a los interesados que estén en la reunión.
Después de la presentación de cada ingeniero, cualquiera de los presentes en la reunión puede hacer preguntas o comentarios sobre el trabajo realizado o la presentación.
Estas preguntas pueden ir desde detalles sobre el proyecto para quienes no conozcan, lo conozcan en su totalidad o pueden ser preguntas sobre porque se decidió seguir un curso de acción en particular.
Desde Producto o miembros de la audiencia que estén más enfocados en la parte del negocio pueden dar feedback sobre si lo que fue presentando coincide con la intención de negocio de lo que se pidió entregar.
Una vez que todas las preguntas y comentarios son respondidos, el próximo ingeniero presentará su trabajo.
En una revisión de sprint, si bien todos pueden hablar, generalmente solo lo hacen los ingenieros que presentan. Entonces, el ingeniero presenta sobre el trabajo que realizaron y luego Producto, QA, Ba y los demás pueden dar feedback y hacer preguntas específicas sobre lo que el ingeniero presentó.
Revisión de ejemplo
Demos una mirada a una revisión de ejemplo y a lo que podría contener.
Vamos a usar el ejemplo de los seis ingenieros de más arriba: dos trabajando en la página de inicio de sesión, dos trabajando en un servicio back-end y dos trabajando en la performance de la base de datos. En ese caso, la lista de presentadores se ve así:
Presentaciones
- Larry: El usuario supera la cantidad máxima de intentos de inicio de sesión y la cuenta se bloquea después del quinto intento incorrecto. El usuario tiene que pedir un nuevo password antes de poder iniciar sesión de nuevo.
- David: El usuario hace clic en el enlace de contraseña olvidada y se emvia un enlace a su correo electrónico. El usuario hace clic en el enlace y puede restablecer su contraseña.
- Premilla: Un servicio de reporte consume el evento "Usuario excede la cantidad máxima de intentos de inicio de sesión" y lo publica en el tablero de reportes.
- Akshat: Un servicio de reporte consume el evento "Usuario hace clic en el enlace de restablecimiento de contraseña" y lo publica en el tablero de reportes.
- Olga: Un usuario administrador puede ver el tablero durante un mes y cargar el reporte dentro de los 2 segundos.
- Trevor: Un usuario administrar puede ver los eventos de varios usuarios en un mismo tablero y cargar el reporte dentro de los 2 segundos.
Como puedes ver, las dos presentaciones sobre la página de inicio de sesión de usuario se hicieron primero, después las dos presentaciones sobre los servicios de reportes, y por último las dos presentaciones sobre la velocidad de respuesta de la base de datos. Esto requiere un menor cambio de contexto para los miembros de la audiencia y también que es posible dar el contexto en la primera de las dos presentaciones agrupadas (esto es, las presentaciones 1, 3 y 5).
Después de la presentación 1 (realizada por Larry), Producto puede preguntarle por qué eligió cinco intentos como el número máximo de intentos antes de que se bloquee la cuenta. Larry puede tener o no una respuesta. Producto puede pedirle un seguimiento sobre este tema e investigar cuál es el estándar de la industria y aplicar la misma lógica que Larry o dejarlo así.
Después de las seis presentaciones, puede haber preguntas, comentarios o pedidos de cambio de cualquier persona de la audiencia. Usualmente, esto va a precipitar una conversación entre los presentes sobre cuál puede ser la mejor manera de realizar estos cambios.
Por ejemplo, de nuevo en el ejemplo de Larry, algunos podrían sugerir que ni se debería usar un nombre de usuario y contraseña, sino una dirección de correo electrónico y un enlace mágico. Esto es lo bueno de la revisión. Tenemos a un montón de gente inteligente en la habitación contribuyendo con su propia experiencia y sabiduría.
Consejos accionables
Here are some tips for what to show, how to show it, and what actually matters during the meeting itself. Aquí tienes un par de consejos sobre qué mostrar, cómo mostrarlo, y lo que realmente importa durante la reunión en sí.
1. Mostrar entregables reales
Primero, siempre muestra software en funcionamiento o demos que funcionen en vez de diapositivas estáticas. Por ejemplo, si estuviste trabajando en una nueva función de inicio de sesión, haz una demostración en vivo. Esto hace que la revisión sea más auténtica y muestre avances tangibles.
2. Alienta el feedback
Segundo, invita a la audiencia a hacer preguntas. Recuérdale a las partes interesadas que sus ideas pueden ayudar a desarrollar nuevas funcionalidades. Anota sus sugerencias y confírmales si alguno de los cambios irán de inmediato a tu lista de pendientes.
3. Sé claro y mantente enfocado
Tercero, mantén un formato simple. Por ejemplo, empieza con un pantallazo general del objetivo del sprint, ve a las demostraciones y termina con un debate corto sobre los próximos pasos.
Evita entrar en profundidad sobre los detalles técnicos. Si el tema requiere más tiempo, organiza una reunión de seguimiento.
4. Coordina los próximos pasos.
Seguido de esto, actualiza tu lista de pendientes con base en lo aprendido en la reunión. Si una funcionalidad requiere un ajuste extra, agrega la tarea de manera inmediata.
Esto ayuda a mantener informado a todo el equipo sobre el plan para el siguiente sprint.
5. Mantenla corta y termina en horario
En la reunión deberías revisar el trabajo del equipo scrum de un solo sprint (dos o tres semanas)
Si la reunión se hace demasiado larga, esto puede significar que tu equipo scrum es demasiado grande (en ese caso, deberías pensar en dividir el equipo en grupos más pequeños) o que no estás siendo eficiente con tus demostraciones.
El tiempo y la atención de las personas son costosos y escasos. Mantén las reuniones a un ciclo ultradriano. Personalmente, trato de limitar todas las reuniones a un máximo de 90 minutos.
Por último, establece un límite firme para la reunión así los participantes se sienten confiados al dar su feedback sin alargar el debate.
Terminar a horario significa respetar el calendario de los demás y mantener al equipo descansado y preparado para el próximo sprint.
En conclusión
Una revisión de sprint les da a las partes interesadas una mirada real sobre el trabajo realizado, las mantiene alineadas sobre los próximos pasos, y permite obtener el feedback que necesitas para hacer crecer tu producto de forma efectiva.
Si te enfocas en mostrar avances reales, tener un dialogo abierto y mantienes las cosas de forma concisa, verás una mejoría en como tu equipo entrega valor.
En su tiempo libre, Ben escribe su blog de tecnología "Just Another Tech Lead" y administra un sitio donde crea calculadoras gratuitas llamado "CalculatorLord.com".