Sprint Review convertida en reporte de avance
En Fintech Andina, el equipo Oro trabaja en Sprints de dos semanas. La Sprint Review dura 25 minutos, se agenda el mismo día que el Sprint Planning y reúne a 18 personas, casi todas del área técnica. La Product Owner, Marta, presenta ella misma la demo y no deja hablar a los desarrolladores. Cumplimiento normativo, riesgos y atención al cliente, que deben aprobar los flujos de onboarding, nunca han asistido: se enteran de los cambios cuando ya están en producción. En las últimas cuatro Sprints, el orden de los diez primeros elementos del Product Backlog no ha cambiado ni una vez, aunque según el propio equipo dos de ellos ya no aportan valor. Los stakeholders piden por correo «un PDF con el avance» y Marta lo envía cada viernes. En la última retrospectiva el equipo concluyó que la Review «es puro teatro» y propuso cancelarla porque «quita tiempo de desarrollo».
1. Diagnostica por qué la Sprint Review no está produciendo inspección y adaptación, relacionando cada síntoma del caso con la regla de Scrum que se está incumpliendo.
Read the worked answer
La Review no falla por duración ni por formato: falla porque no hay inspección del incremento por parte de quien puede adaptar el producto.
- 25 minutos y solo público técnico. La Review existe para inspeccionar el incremento y adaptar el Product Backlog con los stakeholders. Sin cumplimiento, riesgos y atención al cliente en la sala, la inspección se hace entre quienes ya sabían qué se estaba construyendo: no hay información nueva, solo confirmación.
- Marta presenta la demo. Al monopolizar la presentación, el equipo pierde la oportunidad de explicar decisiones y recibir preguntas directas; además, la conversación se vuelve una presentación comercial y no una inspección del trabajo real.
- El top-10 del backlog no cambia en cuatro Sprints. Es la prueba más clara: la Review no produce adaptación. Si la salida es siempre la misma, la entrada no está aportando nada.
- El PDF de los viernes. Es un reporte de estado, la antítesis de la Review: información unidireccional, sin preguntas ni decisiones, que además compite y sustituye al evento.
- El mismo día que el Planning. La Review debe alimentar la planificación; si van seguidas, la adaptación no tiene tiempo de madurar y se convierte en trámite.
Conclusión: el equipo tiene razón en el diagnóstico y se equivoca en la solución. Cancelar la Review elimina la única oportunidad de recibir feedback; lo que hay que eliminar es el formato de reporte.
2. Rediseña la Sprint Review: agenda concreta, a quién invitar y cómo conseguir que cumplimiento normativo participe de forma útil y no como espectador.
Read the worked answer
Antes del evento (48 h): enviar una nota de una página con el Sprint Goal, qué elementos cumplen la Definition of Done y tres preguntas concretas para los asistentes, por ejemplo: ¿qué flujo de onboarding genera más riesgo regulatorio?, ¿qué deberíamos recortar del próximo Sprint?
Agenda para un Sprint de dos semanas (90 minutos):
- 5 min - contexto y Sprint Goal.
- 25 min - demo hecha por quien construyó cada elemento, contra la Definition of Done, con datos reales o entorno de pruebas.
- 20 min - feedback dirigido a las tres preguntas preparadas.
- 15 min - revisión del Product Backlog: qué se añade, qué se reordena, qué se elimina como consecuencia de lo visto.
- 15 min - borrador del próximo Sprint Goal y riesgos.
- 10 min - decisiones y dueños, registrados en el backlog durante la propia sesión.
Invitación a cumplimiento: dejar de tratarlos como audiencia. Acordar con su responsable una presencia mínima trimestral y una revisión asíncrona del incremento en las demás Sprints, con un canal donde sus observaciones entren al backlog. Si solo pueden dar feedback por escrito, ese feedback debe llegar antes de la Review y leerse en ella.
Regla de oro: si al terminar no ha cambiado ningún elemento del Product Backlog, la Review no ha cumplido su propósito.
3. Marta plantea que los clientes y las áreas internas no pueden asistir por confidencialidad y que el PDF es suficiente. ¿Cómo respondes y qué alternativa propones?
Read the worked answer
Hay que separar dos cosas que Marta está mezclando: la restricción de acceso a datos reales y la necesidad de feedback.
Reconocer la restricción y no pelearla. Si el marco regulatorio impide que un área vea datos de clientes, eso es un hecho. Discutirlo desgasta credibilidad y la conversación se vuelve ideológica.
Redefinir la condición de éxito. La pregunta no es si el PDF existe, sino si alguien toma una decisión distinta por haberlo leído. Si el PDF se envía y nunca genera cambios en el backlog, no es un artefacto de inspección: es un ritual de tranquilidad.
Alternativas concretas:
- Sesión reducida con datos enmascarados o sintéticos, para que la demo sea posible sin exponer información real.
- Revisión asíncrona con plazo y pregunta obligatoria: el PDF se sustituye por una grabación de 10 minutos más una pregunta explícita cuya respuesta vence en 72 horas y se registra en el backlog.
- Un representante por área, no el área entera: una persona de cumplimiento con mandato para opinar, en lugar de distribución masiva de documentos.
- Revisión trimestral ampliada con las áreas que tienen poder de veto.
Cierre: aceptar el PDF como canal secundario, nunca como sustituto. Y medirlo: contar cuántas decisiones del backlog se originan en ese canal en las próximas cuatro Sprints. Si el número es cero, el problema no es la confidencialidad, es que el documento no se lee.