Explore

Ceremonias

Sprint review

Sitio elaborado por

Jorge Pérez Colín⁠

⁠

Este es el final público del sprint se invita a todas y cada una de las partes interesadas (steakholders) a esta reunión. Es la oportunidad del equipo para mostrar sus logros, las historias que han cumplido con la definición del equipo de hecho. Esta es también la oportunidad de las partes interesadas para ver cómo el producto se ha mejorado gradualmente en el transcurso del sprint.

Si hay historias a las que el equipo se comprometió, pero no completó, este es el momento de compartir esa información con las partes interesadas. Luego viene el evento principal de esta reunión: demostrar las historias que se hicieron. Sin duda, las partes interesadas tendrán comentarios e ideas, y el propietario del producto y los miembros del equipo recopilarán estos comentarios, lo que ayudará al equipo a inspeccionar y adaptar el producto.

Esta reunión:

No es una reunión de toma de decisiones.

No es cuando decidimos si las historias están hechas; que debe suceder antes de esta reunión.

No es cuando tomamos decisiones o compromisos sobre lo que el equipo hará durante el próximo sprint; eso sucede en la planificación del sprint.

¿Cuánto tiempo debe ser la revisión del sprint? Recomendamos programar de media a una hora por cada semana de desarrollo. Es decir, si tienes un sprint de una semana, entonces esta reunión podría ser de 30 a 60 minutos. Si tienes un sprint de dos semanas, entonces esta reunión podría necesitar de una a dos horas. Después de haberlo hecho unas cuantas veces, sabrá cuánto tiempo necesita su equipo: ¡inspeccione y adapte!

Presentación para un Sprint Review

1. Portada

Título de la presentación: Sprint Review [Número o Nombre del Sprint]

Proyecto/Producto: [Nombre del Proyecto o Producto]

Fecha: [Fecha de la Revisión]

Equipo: [Nombre o Identificador del Equipo]

Objetivo: Dar la bienvenida y contextualizar sobre qué Sprint y de qué proyecto se hablará.

⁠

2. Introducción y Objetivos

Breve introducción del proyecto: Explica en una o dos frases el propósito general del producto o iniciativa.

Objetivo principal de este Sprint: Menciona el “por qué” de lo que se priorizó; qué se buscaba lograr con este Sprint.

Agenda del día:

Objetivos del Sprint

Historias de usuario completadas y demostración

Métricas y resultados

Lecciones aprendidas

Próximos pasos y cierre

Objetivo: Enmarcar claramente qué se revisará y por qué es importante.

⁠

3. Objetivos del Sprint

Listado de objetivos clave:

Objetivo A (e.g., “Mejorar la experiencia de usuario en el flujo de registro”)

Objetivo B (e.g., “Implementar la lógica de facturación para clientes corporativos”)

Objetivo C (e.g., “Reducir el tiempo de respuesta del servidor en un 15 %”)

Objetivo: Recordar al equipo y stakeholders los propósitos específicos que marcaron la planificación.

⁠

4. Historias de Usuario y Entregables

Resumen de Historias de Usuario completadas:

HU-1: “Como [rol], quiero [funcionalidad], para [beneficio]”

Estado: Hecha

Notas relevantes: Hallazgos, mejoras, obstáculos resueltos

HU-2: “Como [rol], quiero…”

Estado: Hecha

Notas relevantes: Hallazgos, mejoras, obstáculos resueltos

Ítems no completados (si aplica): Explicar brevemente el porqué.

Objetivo: Mostrar qué se ha construido y validado, destacando el valor entregado.

⁠

5. Demostración (Demo)

Mostrar funcionalidad o prototipo: Guiar a los participantes a través de las características desarrolladas.

Explicar el flujo de usuario: Destacar la experiencia desde la perspectiva del usuario.

Demostrar mejoras técnicas (si corresponde): Mostrar métricas de rendimiento, ejemplos de código o antes/después de la infraestructura.

Objetivo: Validar el producto “tangible” del Sprint y recibir retroalimentación inmediata.

⁠

6. Métricas e Indicadores

⁠

Burn down chart⁠

. Velocidad del equipo (story points / tareas completadas):

Comparar con sprints anteriores y analizar la tendencia.

Calidad (bugs encontrados, porcentajes de pruebas aprobadas):

Mostrar la evolución en la calidad; incluir gráficos o tablas.

Otros indicadores relevantes (tiempo de carga, retención de usuarios, etc.):

Seleccionar las métricas más relevantes para el negocio y el producto.

Objetivo: Proveer datos cuantitativos que ayuden a evaluar el rendimiento del equipo y la calidad del producto.

⁠

7. Lecciones Aprendidas

Principales logros:

Ejemplo: “El enfoque colaborativo con el equipo de diseño facilitó la entrega de la funcionalidad X antes de lo previsto.”

Principales desafíos:

Ejemplo: “La configuración del entorno de pruebas no estaba lista, lo que retrasó el inicio de las pruebas de integración.”

Oportunidades de mejora:

Propuestas de mejoras de proceso, comunicación o tecnología para próximos sprints.

Objetivo: Mostrar reflexiones objetivas sobre qué se hizo bien y en qué se puede mejorar.

⁠

8. Próximos Pasos

Qué se planea para el próximo sprint:

Ejemplo: “Continuar con la refactorización del módulo de pagos.”

Tareas pendientes y dependencias:

Resaltar cualquier bloqueador o dependencia con otro equipo/área.

Preguntas y comentarios:

Abrir el espacio a preguntas de los stakeholders para aclaraciones o sugerencias.

Objetivo: Enfocar la atención en el futuro inmediato, manteniendo la transparencia de lo que vendrá.

⁠

After Action Review⁠

⁠

Story time⁠

⁠

Scrum⁠

⁠

Retrospectiva⁠

⁠

Wiki Agile⁠

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.