7 min lectura • Guide 540 of 877
Gestionando Refinamiento del Sprint Backlog
Objetivos del Refinamiento
| Objetivo | Indicador | Beneficio |
|---|---|---|
| Listo para sprint | Cumple DoR | Planning más rápido |
| Bien estimado | Consenso del equipo | Velocity predecible |
| Tamaño correcto | Tareas de 1-3 días | Trabajo manejable |
| Priorizado | Stack-ranked | Enfoque claro |
| Entendido | Preguntas respondidas | Menos confusión mid-sprint |
Proceso de Refinamiento
WORKFLOW DE REFINAMIENTO DE BACKLOG
ANTES DE LA SESIÓN (Product Owner + Tech Lead):
┌─────────────────────────────────────────────────┐
│ 1. Revisar solicitudes entrantes │
│ 2. Redactar user stories con criterios │
│ 3. Identificar items que necesitan input técnico│
│ 4. Pre-priorizar items a discutir │
│ 5. Marcar items con dependencias o riesgos │
│ │
│ Tiempo: 1-2 horas antes de sesión semanal │
└─────────────────────────────────────────────────┘
│
▼
SESIÓN DE REFINAMIENTO (Equipo Completo):
┌─────────────────────────────────────────────────┐
│ Duración: 1 hora por semana │
│ │
│ Agenda: │
│ 1. Revisar items nuevos (15 min) │
│ └── PO presenta, equipo pregunta │
│ │
│ 2. Clarificar items existentes (20 min) │
│ └── Responder preguntas, actualizar stories │
│ │
│ 3. Estimar items listos (20 min) │
│ └── Planning poker o similar │
│ │
│ 4. Identificar riesgos/dependencias (5 min) │
│ └── Marcar para seguimiento │
└─────────────────────────────────────────────────┘
│
▼
DESPUÉS DE LA SESIÓN (Continuo):
┌─────────────────────────────────────────────────┐
│ 1. Actualizar stories con clarificaciones │
│ 2. Investigar preguntas técnicas marcadas │
│ 3. Resolver dependencias │
│ 4. Dividir stories si muy grandes │
│ 5. Mantener backlog priorizado │
└─────────────────────────────────────────────────┘
Definición de Ready
DEFINICIÓN DE READY (DoR)
ANTES DE ENTRAR AL SPRINT, ITEM DEBE TENER:
CLARIDAD:
☐ User story sigue formato (Como... Quiero... Para que...)
☐ Criterios de aceptación específicos y testeables
☐ Diseños UI adjuntos (si aplica)
☐ Approach técnico entendido
TAMAÑO:
☐ Estimado por el equipo
☐ Se puede completar en 1-3 días
☐ Si es más grande, dividido en sub-tareas
DEPENDENCIAS:
☐ Sin dependencias bloqueantes, O
☐ Dependencias programadas para completar primero
☐ Dependencias externas tienen timeline
PRIORIDAD:
☐ Product Owner ha priorizado
☐ Alineación con stakeholders confirmada
TESTABILIDAD:
☐ Escenarios de test identificados
☐ Edge cases documentados
Guías de Sizing de Stories
REFERENCIA DE SIZING DE STORIES
1 PUNTO - Trivial
┌─────────────────────────────────────────────────┐
│ • Cambio de configuración │
│ • Actualización de texto │
│ • Bug fix simple con causa conocida │
│ Tiempo: < 4 horas │
└─────────────────────────────────────────────────┘
2 PUNTOS - Pequeño
┌─────────────────────────────────────────────────┐
│ • Agregar campo a formulario existente │
│ • Endpoint API simple │
│ • Componente UI básico │
│ Tiempo: 4-8 horas (medio día a día completo) │
└─────────────────────────────────────────────────┘
3 PUNTOS - Mediano
┌─────────────────────────────────────────────────┐
│ • Nueva feature con patrón conocido │
│ • Complejidad moderada │
│ • Algo de testing/edge cases │
│ Tiempo: 1-2 días │
└─────────────────────────────────────────────────┘
5 PUNTOS - Grande
┌─────────────────────────────────────────────────┐
│ • Nueva feature con algunas incógnitas │
│ • Múltiples componentes involucrados │
│ • Integración con sistema externo │
│ Tiempo: 2-3 días │
│ Considerar: ¿Se puede dividir? │
└─────────────────────────────────────────────────┘
8 PUNTOS - Muy Grande
┌─────────────────────────────────────────────────┐
│ • Feature compleja │
│ • Incógnitas significativas │
│ • Coordinación cross-team │
│ Tiempo: 3-5 días │
│ Acción: Definitivamente debe dividirse │
└─────────────────────────────────────────────────┘
13+ PUNTOS - Épica
┌─────────────────────────────────────────────────┐
│ Demasiado grande para un sprint │
│ Acción: DEBE ser descompuesta │
└─────────────────────────────────────────────────┘
Template de Sesión de Refinamiento
AGENDA DE SESIÓN DE REFINAMIENTO
APERTURA (2 min):
┌─────────────────────────────────────────────────┐
│ • Revisar objetivos de la sesión │
│ • Check: ¿Cuántos items necesitan refinamiento?│
│ • Recordatorio de time-box │
└─────────────────────────────────────────────────┘
REVISIÓN DE ITEMS (50 min para ~5 items):
┌─────────────────────────────────────────────────┐
│ Para cada item (10 min máx por item): │
│ │
│ 1. PO lee story y criterios de aceptación │
│ 2. Equipo hace preguntas de clarificación │
│ 3. Discusión técnica si necesario │
│ 4. Estimación (si está listo) │
│ 5. Marcar como listo o anotar seguimientos │
│ │
│ Si no se puede resolver en 10 min: │
│ └── Dejar para seguimiento offline │
└─────────────────────────────────────────────────┘
CIERRE (5 min):
┌─────────────────────────────────────────────────┐
│ • Recapitular items refinados y estimaciones │
│ • Listar acciones de seguimiento con owners │
│ • Confirmar suficiente listo para próximo sprint│
│ • Nota: Backlog listo debe tener 2 sprints │
└─────────────────────────────────────────────────┘
Métricas de Salud del Backlog
DASHBOARD DE SALUD DEL BACKLOG
READINESS:
┌─────────────────────────────────────────────────┐
│ Items cumpliendo Definition of Ready: │
│ │
│ Listo para próximo sprint: 35 pts ✓ │
│ (Target: 1.5x capacidad de sprint de 30) │
│ │
│ Listo para sprint después: 28 pts ⚠ │
│ (Target: 1x capacidad de sprint) │
│ │
│ Necesita refinamiento: 45 pts │
│ (Pipeline para futuro) │
└─────────────────────────────────────────────────┘
COBERTURA DE ESTIMACIÓN:
┌─────────────────────────────────────────────────┐
│ Top 20 items: │
│ ├── Estimados: 18 (90%) ✓ │
│ └── Sin estimar: 2 (10%) ✓ │
│ │
│ Todos los items: │
│ ├── Estimados: 45 (65%) │
│ └── Sin estimar: 24 (35%) │
│ (Items más abajo pueden esperar) │
└─────────────────────────────────────────────────┘
DISTRIBUCIÓN DE TAMAÑO DE STORIES:
┌─────────────────────────────────────────────────┐
│ Desglose de items listos: │
│ 1-2 puntos: 8 items ████████ │
│ 3 puntos: 5 items █████ │
│ 5 puntos: 4 items ████ │
│ 8+ puntos: 1 item █ (necesita división) │
│ │
│ Salud: Buena (mayoría < 5 puntos) │
└─────────────────────────────────────────────────┘
Mejores Prácticas
- Refinar continuamente no solo antes del planning
- Mantener 2 sprints de items listos
- Time-box discusiones para prevenir rabbit holes
- Dividir stories grandes proactivamente
- Documentar preguntas resueltas en la sesión
- Pre-trabajo del PO hace sesiones eficientes
- Rastrear métricas de readiness para salud
- Involucrar personas correctas para cada item
Anti-Patrones
✗ Refinamiento solo durante sprint planning
✗ Sin Definition of Ready
✗ Reuniones de refinamiento de 3+ horas
✗ Estimar sin entender
✗ PO trabaja solo en todos los items
✗ Nunca dividir stories grandes
Soluciones Relacionadas con GitScrum
- Sprint Planning Best Practices
- Creando Product Backlogs Efectivos
- Precisión de Estimación de Esfuerzo
- Gestión de Velocity de Sprint
Conclusión
El refinamiento efectivo del backlog es la base de sprints exitosos. GitScrum proporciona las herramientas para mantener items bien documentados con criterios de aceptación claros, rastrear estimaciones y readiness, y asegurar que el equipo siempre tenga trabajo listo para el próximo sprint. Al invertir tiempo en refinamiento regular, los equipos pueden hacer el sprint planning más rápido y reducir sorpresas significativamente.