10 min lectura • Guide 52 of 877
Construyendo Retrospectivas de Sprint Efectivas
Las retrospectivas son la ceremonia más subutilizada en agile. Bien hechas, componen mejoras del equipo con el tiempo. Mal hechas, se convierten en sesiones de quejas que no cambian nada. GitScrum proporciona la estructura para ejecutar retrospectivas que identifican problemas reales, generan mejoras accionables y rastrean seguimiento a través de sprints.
El Problema de la Retrospectiva
Por qué la mayoría de las retrospectivas fallan en crear cambio:
| Patrón Común | Resultado |
|---|---|
| Mismos problemas cada sprint | Nada se resuelve, equipo pierde fe |
| Desahogo sin soluciones | Se siente bien momentáneamente, sin mejora |
| Acciones desaparecen | Items acordados nunca tracked o completados |
| Voces más fuertes dominan | Introvertidos y nuevos no contribuyen |
| Sin datos, solo sentimientos | Opiniones subjetivas sin evidencia |
| Saltar cuando hay prisa | Mejora se vuelve opcional |
Preparación de Retrospectiva
Recolección de Datos Antes de la Reunión
RECOLECCIÓN DATOS PRE-RETROSPECTIVA:
┌─────────────────────────────────────────────────────────────┐
│ RESUMEN MÉTRICAS SPRINT 24 │
├─────────────────────────────────────────────────────────────┤
│ │
│ VELOCIDAD & COMPLETITUD: │
│ ├── Comprometido: 42 puntos │
│ ├── Completado: 38 puntos (90%) │
│ ├── Carry over: 4 puntos (1 historia) │
│ └── Tendencia: ↓ desde 95% sprint pasado │
│ │
│ MÉTRICAS FLUJO: │
│ ├── Cycle time promedio: 3.2 días (↑ desde 2.8) │
│ ├── Historias bloqueadas: 4 (tiempo bloqueado: 6 días) │
│ └── Violaciones WIP: 2 ocasiones │
│ │
│ CALIDAD: │
│ ├── Bugs encontrados en sprint: 3 │
│ ├── Bugs escapados a prod: 1 │
│ └── Deuda técnica agregada: 2 items flaggeados │
│ │
│ INTERRUPCIONES: │
│ ├── Trabajo no planificado: 5 puntos │
│ ├── Cambios scope: 2 historias modificadas │
│ └── Uso buffer: 80% │
│ │
│ SALUD EQUIPO (encuesta pulso): │
│ ├── Satisfacción general: 3.8/5 (↓ desde 4.1) │
│ ├── Ritmo sostenible: 3.2/5 │
│ └── Claridad objetivos: 4.2/5 │
│ │
└─────────────────────────────────────────────────────────────┘
Pre-Recolección Async
INPUT RETRO ASYNC (GitScrum Discussions):
┌─────────────────────────────────────────────────────────────┐
│ 📝 Input Retrospectiva Sprint 24 │
│ Fecha límite: Viernes 4pm (antes de retro 5pm) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Por favor agreguen pensamientos (opción anónima disponible):│
│ │
│ QUÉ SALIÓ BIEN (seguir haciendo): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Pair programming en feature auth fue genial - @Kim ││
│ │ • Daily standups se mantuvieron bajo 10 min - @Alex ││
│ │ • Sprint goal claro ayudó a priorizar - [anon] ││
│ │ • Buena colaboración con equipo diseño - @Jordan ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ QUÉ NO SALIÓ BIEN (parar o cambiar): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Bloqueados en spec API por 3 días - @Sam ││
│ │ • Demasiadas reuniones el martes - [anon] ││
│ │ • Historia mucho más grande que estimado - @Kim ││
│ │ • Requisitos poco claros en feature dashboard - @Pat ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IDEAS & EXPERIMENTOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Probar mob programming para historias complejas ││
│ │ • Bloquear mañanas de martes para trabajo profundo ││
│ │ • Agregar revisión contrato API a DoR - @Sam ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Formatos de Retrospectiva
Formato Estándar (45-60 min)
AGENDA RETROSPECTIVA:
┌─────────────────────────────────────────────────────────────┐
│ TIEMPO│ ACTIVIDAD │
├───────┼─────────────────────────────────────────────────────┤
│ 5min │ APERTURA │
│ │ • Revisar acciones retro anterior │
│ │ • Compartir métricas sprint (sin juzgar) │
│ │ • Recordatorio reglas base │
│ │ │
│ 10min │ RECOPILAR DATOS │
│ │ • Revisar input async ya enviado │
│ │ • Agregar items de último momento │
│ │ • Clarificar items poco claros │
│ │ │
│ 15min │ GENERAR INSIGHTS │
│ │ • Votación por puntos en items más impactantes │
│ │ • Discutir top 2-3 items profundamente │
│ │ • Identificar causas raíz, no solo síntomas │
│ │ │
│ 15min │ DECIDIR ACCIONES │
│ │ • Convertir insights en experimentos específicos │
│ │ • Asignar owner para cada acción │
│ │ • Definir criterios éxito y timeline │
│ │ │
│ 5min │ CIERRE │
│ │ • Resumir acciones acordadas │
│ │ • Feedback retro (¿cómo estuvo esta retro?) │
│ │ • Crear action items en GitScrum │
│ │
└─────────────────────────────────────────────────────────────┘
Formato Rápido (20 min)
RETROSPECTIVA RÁPIDA:
┌─────────────────────────────────────────────────────────────┐
│ PARA: Sprints cortos, equipos estables, períodos tranquilos │
├─────────────────────────────────────────────────────────────┤
│ │
│ 3min │ Estado acciones anteriores (rápido pass/fail) │
│ │
│ 5min │ Check-in una palabra de cada persona │
│ │ "Describe este sprint en una palabra" │
│ │ Explicación rápida por qué │
│ │
│ 7min │ ¿Cuál es la UNA cosa que deberíamos mejorar? │
│ │ Cada persona escribe una sugerencia │
│ │ Votación rápida, elegir item top │
│ │
│ 5min │ Definir acción para item top │
│ │ Quién, qué, para cuándo │
│ │ Criterios de éxito │
│ │
└─────────────────────────────────────────────────────────────┘
Análisis de Causa Raíz
Técnica de los Cinco Por Qué
EJEMPLO: ¿Por qué no cumplimos el compromiso del sprint?
┌─────────────────────────────────────────────────────────────┐
│ ANÁLISIS CINCO POR QUÉ │
├─────────────────────────────────────────────────────────────┤
│ │
│ SÍNTOMA: No completamos la historia del dashboard (4 pts) │
│ │
│ POR QUÉ 1: ¿Por qué no la completamos? │
│ → "Se nos acabó el tiempo; era más grande que estimado" │
│ │
│ POR QUÉ 2: ¿Por qué era más grande que estimado? │
│ → "El API que necesitábamos no estaba lista, tuvimos que │
│ construir solución temporal" │
│ │
│ POR QUÉ 3: ¿Por qué no estaba lista el API? │
│ → "Equipo backend trabajando en prioridad diferente" │
│ │
│ POR QUÉ 4: ¿Por qué no sabíamos de esta dependencia? │
│ → "No revisamos dependencias en sprint planning" │
│ │
│ POR QUÉ 5: ¿Por qué no revisamos dependencias en planning? │
│ → "No tenemos checklist para eso, y vamos apurados" │
│ │
│ CAUSA RAÍZ: Falta revisión dependencias en proceso planning │
│ │
│ ACCIÓN: Agregar "check dependencias" a Definition of Ready │
│ Revisar dependencias cross-team antes de comprometer│
│ │
└─────────────────────────────────────────────────────────────┘
Tracking de Acciones
Framework de Experimento
ACTION ITEM COMO EXPERIMENTO:
┌─────────────────────────────────────────────────────────────┐
│ 🧪 EXPERIMENTO: SLA Revisión PR 24 Horas │
│ Mejora Sprint 25 │
├─────────────────────────────────────────────────────────────┤
│ │
│ HIPÓTESIS: │
│ "Si implementamos SLA revisión PR de 24 horas, entonces │
│ cycle time disminuirá de 3.2 días a 2.5 días o menos." │
│ │
│ OWNER: @Alex │
│ DURACIÓN: 2 sprints (Sprint 25-26) │
│ │
│ CRITERIOS ÉXITO: │
│ ├── 90% PRs revisados dentro de 24 horas │
│ ├── Cycle time ≤ 2.5 días │
│ └── Sin disminución calidad revisión │
│ │
│ IMPLEMENTACIÓN: │
│ ├── Agregar recordatorio Slack para PRs abiertos >12h │
│ ├── Equipo acuerda revisar cola PR dos veces al día │
│ ├── Limitar tamaño PR a <400 líneas de código │
│ └── Trackear tiempos revisión en métricas sprint │
│ │
│ MEDICIÓN: │
│ ├── Tiempo revisión PR (métricas GitHub/GitLab) │
│ ├── Cycle time general (analytics GitScrum) │
│ └── Bugs encontrados en code review vs. después merge │
│ │
│ PLAN ROLLBACK: │
│ Si equipo se siente apurado o calidad baja, revertir y │
│ probar solución alternativa. │
│ │
└─────────────────────────────────────────────────────────────┘
Board de Acciones en GitScrum
TRACKING ACCIONES RETRO:
┌─────────────────────────────────────────────────────────────┐
│ 📋 Board Acciones Retrospectiva │
├─────────────────────────────────────────────────────────────┤
│ │
│ POR HACER │ EN PROGRESO │ HECHO (Este Trimestre) │
│ ───────────────┼──────────────────┼─────────────────────── │
│ │ │ │
│ Agregar check │ SLA PR 24h │ ✓ Timer daily standup │
│ dependencias │ @Alex │ (Sprint 22) │
│ a DoR │ Sprint 25-26 │ │
│ @Sam │ │ ✓ Rotación pair │
│ Sprint 26 │ Bloquear martes │ programming (S23) │
│ │ mañanas │ │
│ Crear checklist│ @Jordan │ ✓ Opción standup │
│ revisión API │ Sprint 25 │ async (Sprint 23) │
│ @Pat │ │ │
│ Sprint 26 │ │ │
│ │
│ LABELS: │
│ 🔴 Vencido | 🟡 En Riesgo | 🟢 En Track │
│ │
│ MÉTRICAS: │
│ ├── Acciones creadas este trimestre: 12 │
│ ├── Acciones completadas: 8 (67%) │
│ └── Acciones vencidas: 2 │
│ │
└─────────────────────────────────────────────────────────────┘
Técnicas de Facilitación
Asegurando Participación
FACILITACIÓN INCLUSIVA:
┌─────────────────────────────────────────────────────────────┐
│ TÉCNICAS PARA PARTICIPACIÓN BALANCEADA │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. ESCRITURA SILENCIOSA PRIMERO │
│ Todos escriben pensamientos antes de discusión │
│ Previene que voces fuertes anclen │
│ │
│ 2. COMPARTIR ROUND-ROBIN │
│ Cada persona comparte un item en turno │
│ Sin interrupciones durante turno de alguien │
│ Opción de pasar disponible │
│ │
│ 3. OPCIÓN INPUT ANÓNIMO │
│ Permitir envío anónimo para temas sensibles │
│ GitScrum Discussion comentarios anónimos habilitados │
│ │
│ 4. VOTACIÓN POR PUNTOS │
│ Todos tienen votos iguales (ej: 3 puntos) │
│ Votación silenciosa previene influencia │
│ │
│ 5. BREAKOUTS GRUPOS PEQUEÑOS │
│ Grupos 2-3 personas para discusión profunda │
│ Introvertidos frecuentemente más cómodos │
│ │
│ 6. ROTAR FACILITADOR │
│ Persona diferente lidera cada retro │
│ Perspectivas frescas, ownership compartido │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
Hacer
RETROSPECTIVAS EFECTIVAS:
✓ PREPARAR CON DATOS
Traer métricas, no solo opiniones
✓ CREAR SEGURIDAD
Opciones anónimas, sin culpa, mirando adelante
✓ ENFOCARSE EN POCAS ACCIONES
2-3 acciones bien ejecutadas > 10 olvidadas
✓ HACER ACCIONES ESPECÍFICAS
Owner, timeline, criterios éxito, tracked en GitScrum
✓ DAR SEGUIMIENTO
Revisar acciones anteriores, celebrar completadas
✓ VARIAR EL FORMATO
Mantenerlo fresco, emparejar formato a situación
✓ PROTEGER EL TIEMPO
Nunca saltarse retros, incluso cuando hay prisa
No Hacer
ANTI-PATRONES RETROSPECTIVA:
✗ CULPAR INDIVIDUOS
Enfocarse en proceso, no personas
✗ TODO HABLAR, SIN ACCIÓN
Si no puedes comprometerte, no aceptes
✗ MANAGER DOMINA
Crear espacio para voces del equipo
✗ IGNORAR REPETICIÓN
Mismo issue = solución anterior no funcionó
✗ CORRER
Discusión de calidad > marcar casilla