8 min lectura • Guide 79 of 877
Manejando Cambios de Alcance a Mitad de Sprint
Cambios de alcance durante un sprint son realidad, no fracaso. Mercados cambian, prioridades evolucionan, y nueva información emerge. La pregunta no es si el alcance cambiará, sino cómo manejar cambios sin destruir el enfoque del equipo o compromisos del sprint. GitScrum proporciona la estructura para evaluar, comunicar, e integrar cambios de alcance mientras protege la integridad del sprint.
Entendiendo Impacto del Cambio de Alcance
Tipos de Cambios a Mitad de Sprint
CATEGORÍAS DE CAMBIO DE ALCANCE:
┌─────────────────────────────────────────────────────────────┐
│ TIPOS Y RESPUESTAS TÍPICAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ EMERGENCIA (Debe abordarse inmediatamente) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Ejemplos: ││
│ │ • Caída producción afectando usuarios ││
│ │ • Vulnerabilidad seguridad descubierta ││
│ │ • Fecha límite cumplimiento regulatorio ││
│ │ • Cambio requerimiento legal ││
│ │ ││
│ │ Respuesta: Agregar al sprint inmediatamente ││
│ │ Algo más debe salir ││
│ │ Documentar por qué para retrospectiva ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALTA PRIORIDAD (Importante pero no emergencia) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Ejemplos: ││
│ │ • Issue bloqueante de cliente clave ││
│ │ • Nueva oportunidad negocio con fecha límite ││
│ │ • Dependencia descubierta afectando roadmap ││
│ │ ││
│ │ Respuesta: Evaluar tamaño y capacidad sprint ││
│ │ ¿Puede esperar 3-5 días para próximo sprint? ││
│ │ Si no, negociar intercambio alcance ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MEJORA (Bueno tener) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Ejemplos: ││
│ │ • Idea mejora de stakeholder ││
│ │ • Sugerencia mejora UX ││
│ │ • Oportunidad pagar deuda técnica ││
│ │ ││
│ │ Respuesta: Agregar a backlog, priorizar normalmente ││
│ │ No interrumpir sprint ││
│ │ Discutir en próxima planificación ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SCOPE CREEP (Expansión feature) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Ejemplos: ││
│ │ • "Ya que estás ahí, podrías también..." ││
│ │ • Gold-plating de requerimientos ││
│ │ • Complejidad no descubierta emergiendo ││
│ │ ││
│ │ Respuesta: Separar alcance original de expansión ││
│ │ Completar alcance comprometido primero ││
│ │ Expansión va al backlog ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Evaluación de Impacto
EVALUANDO IMPACTO DEL CAMBIO:
┌─────────────────────────────────────────────────────────────┐
│ MATRIZ IMPACTO CAMBIO │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TAMAÑO DEL CAMBIO ││
│ │ Pequeño Mediano Grande ││
│ │ ┌──────────┬──────────┬──────────┐ ││
│ │ Inicio │ 🟢 │ 🟢 │ 🟡 │ ││
│ │ (Día │ Puede │ Swap + │ Negociar │ ││
│ │ 1-2) │ intercamb │ ajustar │ alcance │ ││
│ │ S ├──────────┼──────────┼──────────┤ ││
│ │ P Mitad │ 🟢 │ 🟡 │ 🔴 │ ││
│ │ R (Día │ Puede │ Riesgo │ Próximo │ ││
│ │ I 3-6) │ cuidado │ burndown │ sprint │ ││
│ │ N ├──────────┼──────────┼──────────┤ ││
│ │ T Final │ 🟡 │ 🔴 │ 🔴 │ ││
│ │ (Día │ Solo si │ Próximo │ Próximo │ ││
│ │ 7-10) │ urgente │ sprint │ sprint │ ││
│ │ └──────────┴──────────┴──────────┘ ││
│ │ ││
│ │ 🟢 Bajo riesgo - usualmente puede acomodarse ││
│ │ 🟡 Riesgo medio - requiere negociación cuidadosa ││
│ │ 🔴 Alto riesgo - proteger sprint, diferir a próximo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Gestión de Alcance GitScrum
Documentando Solicitudes de Cambio
USANDO DISCUSSIONS PARA SOLICITUDES DE CAMBIO:
Antes de interrumpir sprint:
┌─────────────────────────────────────────────────────────────┐
│ DISCUSSION: Solicitud Cambio Alcance │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📋 Solicitud: Agregar lógica reintento pago │
│ │
│ ## Detalles Solicitud │
│ **Solicitado por:** @stakeholder │
│ **Sprint:** 12 (Día 4 de 10) │
│ **Urgencia reclamada:** Alta │
│ │
│ ## Análisis Impacto │
│ **Esfuerzo estimado:** 5 story points │
│ **Capacidad sprint restante:** 22 pts │
│ **Impacto objetivo sprint:** Retrasaría objetivo │
│ │
│ ## Opciones │
│ 1. ✅ Agregar a próximo sprint (menor riesgo) │
│ 2. ⚠️ Intercambiar por PROJ-78 docs API (puntos iguales) │
│ 3. 🔴 Agregar sin quitar (riesgo burndown) │
│ │
│ ## Decisión │
│ [A discutir en sync de equipo] │
│ │
└─────────────────────────────────────────────────────────────┘
Seguimiento Alcance Sprint
RASTREANDO ALCANCE ORIGINAL vs ACTUAL:
┌─────────────────────────────────────────────────────────────┐
│ VISIBILIDAD ALCANCE SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Usar labels para rastrear cambios alcance: │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ESTRATEGIA LABELS ││
│ │ ││
│ │ scope:original Tareas comprometidas en planning ││
│ │ scope:added Agregado después inicio sprint ││
│ │ scope:removed Removido del sprint (razón) ││
│ │ scope:emergency Agregado por respuesta emergencia ││
│ │ scope:expanded Tarea original creció en alcance ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Vista filtrada tablero: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SPRINT 12 - Estado Alcance ││
│ │ ││
│ │ Comprometido: 42 pts (10 items) ││
│ │ ├── scope:original 37 pts (8 items) ││
│ │ ├── scope:added 5 pts (2 items) ││
│ │ └── scope:removed -5 pts (1 item → backlog) ││
│ │ ││
│ │ Cambio neto: 0 pts (intercambio balanceado) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Protegiendo Enfoque del Equipo
Estrategia Buffer
PLANIFICANDO PARA CAMBIO:
┌─────────────────────────────────────────────────────────────┐
│ CONSTRUYENDO FLEXIBILIDAD EN SPRINTS │
├─────────────────────────────────────────────────────────────┤
│ │
│ BUFFER CAPACIDAD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Si velocidad equipo es 40 pts, no comprometer 40 pts ││
│ │ ││
│ │ Capacidad equipo: 40 pts (velocidad histórica) ││
│ │ Trabajo objetivo: 32 pts (80%) ││
│ │ Buffer: 8 pts (20%) ││
│ │ ││
│ │ Usos buffer: ││
│ │ • Cambios alcance inesperados ││
│ │ • Tareas tomando más de estimado ││
│ │ • Bug fixes e issues soporte ││
│ │ • Si no usado, traer próximos items backlog ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OBJETIVOS STRETCH: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Identificar items bajo riesgo para traer si hay cap: ││
│ │ ││
│ │ Compromiso core: 32 pts ││
│ │ Stretch goal 1: 5 pts (documentación) ││
│ │ Stretch goal 2: 3 pts (deuda técnica) ││
│ │ ││
│ │ Stretch goals son primeros en sacrificarse si ││
│ │ cambios alcance llegan a mitad sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Patrones Comunicación
Updates Stakeholders
COMUNICANDO CAMBIOS ALCANCE:
┌─────────────────────────────────────────────────────────────┐
│ TRANSPARENCIA SOBRE CAMBIOS │
├─────────────────────────────────────────────────────────────┤
│ │
│ Al aceptar cambio en sprint: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Hemos agregado lógica reintento pago a Sprint 12. ││
│ │ Para acomodar esto, documentación API se mueve a ││
│ │ Sprint 13. Objetivo sprint permanece alcanzable." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Al declinar cambio (diferir a próximo sprint): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Lógica reintento pago está priorizada como top item ││
│ │ para Sprint 13, iniciando enero 20. ││
│ │ ││
│ │ Agregarlo a Sprint 12 arriesgaría nuestro compromiso ││
│ │ con milestone beta launch del 15 de febrero." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Midiendo Estabilidad Alcance
Métricas Cambio Alcance
RASTREANDO PATRONES CAMBIO:
┌─────────────────────────────────────────────────────────────┐
│ MÉTRICAS PARA RETROSPECTIVAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MÉTRICA │ OBJETIVO │ ACTUAL │ ESTADO ││
│ │────────────────────────┼───────────┼────────┼──────────││
│ │ Estabilidad alcance │ 85%+ │ 88% │ 🟢 ││
│ │ (pts completados / pts │ │ │ ││
│ │ originalmente compr) │ │ │ ││
│ │ │ │ │ ││
│ │ Frecuencia cambios │ <3/sprint │ 2 │ 🟢 ││
│ │ (cambios alcance/sprt) │ │ │ ││
│ │ │ │ │ ││
│ │ Adiciones emergencia │ <1/sprint │ 1 │ 🟡 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Preguntas retrospectiva: │
│ • ¿Cambios alcance fueron realmente urgentes? │
│ • ¿Qué causó los cambios? (Análisis patrón) │
│ • ¿Tuvimos buffer adecuado para cambios? │
│ • ¿Cómo afectaron cambios moral y enfoque equipo? │
│ │
└─────────────────────────────────────────────────────────────┘