What is El Problema de las Interrupciones?

Las urgencias no gestionadas destruyen la productividad: - Fallo del sprint — No se puede completar el trabajo planificado - Cambio de contexto — Los desarrolladores pierden flujo constantemente - Colapso de estimaciones — Los planes pierden sentido - Agotamiento del equipo — La lucha constante contra incendios agota

What is Características Clave?

Gestiona solicitudes urgentes y trabajo no planificado en GitScrum sin interrumpir compromisos de sprint usando capacidad de buffer, carriles de interrupción y políticas claras de escalación.

What is Planificación de Capacidad de Buffer?

Gestiona solicitudes urgentes y trabajo no planificado en GitScrum sin interrumpir compromisos de sprint usando capacidad de buffer, carriles de interrupción y políticas claras de escalación.

Manejar Solicitudes Urgentes Sin Descarrilar Sprints

Cada sprint enfrenta solicitudes urgentes inesperadas que amenazan el trabajo planificado. GitScrum proporciona mecanismos de manejo de interrupciones incluyendo planificación de capacidad de buffer, carriles dedicados de interrupción y flujos de escalación.

El Problema de las Interrupciones

Las urgencias no gestionadas destruyen la productividad:

Fallo del sprint — No se puede completar el trabajo planificado
Cambio de contexto — Los desarrolladores pierden flujo constantemente
Colapso de estimaciones — Los planes pierden sentido
Agotamiento del equipo — La lucha constante contra incendios agota
Falsas urgencias — Todo se vuelve "urgente"
Sin predictibilidad — Los stakeholders pierden confianza en la entrega

Solución de Manejo de Interrupciones GitScrum

Construye sistemas que absorban trabajo inesperado:

Características Clave

Característica	Uso para Interrupciones
Capacidad de buffer	Reservar capacidad de sprint para incógnitas
Carriles de interrupción	Columnas dedicadas del board para trabajo urgente
Límites WIP	Prevenir sobrecarga durante interrupciones
Labels/prioridades	Clasificación clara de urgencia
Automatizaciones	Enrutar trabajo urgente apropiadamente

Planificación de Capacidad de Buffer

Estructura de Capacidad del Sprint

Planificación de Capacidad del Sprint:

Capacidad Total Disponible: 100 story points

Asignación:
├── Trabajo Comprometido del Sprint: 75 pts (75%)
│   └── Features e mejoras planificadas
├── Buffer para Interrupciones: 15 pts (15%)
│   └── Solicitudes urgentes esperadas, bugs, soporte
└── Slack/Aprendizaje: 10 pts (10%)
    └── Deuda técnica, exploración, capacitación

Guía de Planificación del Sprint:
"No comprometerse a más de 75 puntos. 
Reservar 15 puntos para interrupciones esperadas.
Si las interrupciones exceden el buffer, eliminar 
los items comprometidos de menor prioridad."

Dimensionamiento del Buffer por Historial del Equipo

Análisis de Interrupciones: Últimos 6 Sprints

Sprint    │ Interrupciones │ Puntos │ % de Capacidad
──────────┼────────────────┼────────┼───────────────
Sprint 18 │ 4 items        │ 12 pts │ 12%
Sprint 17 │ 7 items        │ 18 pts │ 18%  ← Incidente mayor
Sprint 16 │ 3 items        │ 8 pts  │ 8%
Sprint 15 │ 5 items        │ 14 pts │ 14%
Sprint 14 │ 4 items        │ 11 pts │ 11%
Sprint 13 │ 3 items        │ 9 pts  │ 9%

Promedio: 12 pts por sprint (12%)
Buffer recomendado: 15 pts (proporciona margen)

Ajustar si:
├── Sprint con muchas interrupciones → Aumentar buffer
├── Sprint con pocas interrupciones → Mantener buffer, usar para deuda
└── Patrón consistente → Considerar asignación permanente

Carril de Interrupción en el Board

Configuración del Board

Kanban Board con Carril de Interrupción:

┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│ Backlog     │ INTERRUPCIÓN│ En Progreso │ Review      │ Done        │
│             │ 🔴          │             │             │             │
├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤
│ Trabajo     │ URGENTE: Fix│ Feature A   │ Feature B   │ Feature C   │
│ sprint      │ bug de pago │ (planificad)│ (planificad)│ (planificad)│
│ planificado │             │             │             │             │
│ Feature D   │             │ INTERRUPCIÓN│             │ INTERRUPCIÓN│
│ Feature E   │             │ Parche de   │             │ Hotfix      │
│             │             │ seguridad   │             │ desplegado  │
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘

Límite WIP: 2 (columna Interrupción)
Regla: Trabajo de interrupción obtiene desarrollador dedicado
Visualización: Color/label diferente

Clasificación de Interrupciones

Sistema de Clasificación de Urgencia:

🔴 P0 - Crítico (< 1 hora de respuesta)
├── Producción caída
├── Brecha de seguridad activa
├── Pérdida de datos ocurriendo
├── Sistema de pagos roto
└── Acción: Todos, dejar todo

🟠 P1 - Alto (< 4 horas de respuesta)
├── Feature mayor rota para muchos usuarios
├── Impacto significativo en ingresos
├── Escalación importante de cliente
└── Acción: Manejador de interrupciones designado

🟡 P2 - Medio (dentro del sprint)
├── Feature rota para algunos usuarios
├── Existe workaround
├── Solicitud de cliente con deadline
└── Acción: Agregar al sprint si el buffer permite

🟢 P3 - Bajo (próximo sprint)
├── Issues menores
├── Solicitudes nice-to-have
├── Mejoras generales
└── Acción: Backlog para priorización

Rol de Manejador de Interrupciones

Rotación de Deber de Interrupciones

Rotación Semanal de Interrupciones:

Semana 1: @alice (principal), @bob (respaldo)
Semana 2: @bob (principal), @carol (respaldo)  
Semana 3: @carol (principal), @dave (respaldo)
Semana 4: @dave (principal), @alice (respaldo)

Responsabilidades del Manejador de Interrupciones:
├── Monitorear canal #support-engineering
├── Triaje de solicitudes urgentes entrantes
├── Manejar P0/P1 inmediatamente
├── Proteger al resto del equipo de interrupciones
├── Documentar patrones de interrupción
└── Capacidad de sprint: 50% (trabajo planificado)

Beneficios:
├── Una persona cambia de contexto (no todo el equipo)
├── Rotación justa de la carga de interrupciones
├── Tiempo protegido para trabajo enfocado
└── Propiedad clara de issues urgentes

Asignación de Sprint del Manejador

Semana del Manejador de Interrupciones:

@alice Asignación Sprint 19:
├── Trabajo comprometido del sprint: 0 pts
│   └── No asignado a trabajo planificado
├── Capacidad de interrupción: 50% (~20 hrs)
│   └── Manejar todas las solicitudes urgentes
├── Soporte/documentación: 30% (~12 hrs)
│   └── Escribir runbooks, mejorar docs
└── Flexible: 20% (~8 hrs)
    └── Deuda técnica, aprendizaje, ayudar al equipo

Si no ocurren interrupciones:
├── Trabajar en backlog de deuda técnica
├── Mejorar monitoreo/alertas
├── Escribir documentación
└── Pair programming con el equipo en trabajo complejo

Políticas de Escalación

Ruta de Escalación Clara

Matriz de Escalación:

Issue llega via:
├── Slack #support → Triaje por equipo de soporte
├── PagerDuty → Va a ingeniero de guardia
├── Email de cliente → Account manager evalúa
└── Solicitud interna → Solicitante crea ticket

Flujo de Escalación:
1. Soporte crea ticket con evaluación de urgencia
2. Manejador de interrupciones revisa dentro del SLA:
   ├── P0: Inmediatamente (< 15 min)
   ├── P1: < 1 hora
   ├── P2: < 4 horas
   └── P3: Siguiente día hábil
3. Manejador confirma o ajusta prioridad
4. Manejador asigna o agrega al sprint
5. Resolución rastreada en el ticket

Reglas de Auto-Escalación:
├── P0 sin reconocer > 15 min → Pagar a respaldo
├── P1 sin reconocer > 1 hr → Pagar a respaldo + manager
└── Cualquier issue abierto > SLA → Notificar manager

Comunicación con Stakeholders

Template de Solicitud de Interrupción:

Al solicitar trabajo urgente:

Asunto: [URGENTE P1] Pagos fallando para cuentas enterprise

Qué está pasando:
Clientes enterprise viendo errores de pago desde las 2pm

Impacto:
- ~50 clientes afectados
- $20K ingresos potenciales en riesgo
- 3 quejas de clientes recibidas

Workaround:
Procesamiento manual de pagos disponible (lento)

Acción solicitada:
Arreglar integración de pago dentro de 4 horas

Solicitado por: @sarah (Account Manager)
Manager aprobador: @mike (VP Ventas)

---

Respuesta de Engineering:

Reconocido: 2:15pm por @alice
Estado actual: Investigando
ETA: Diagnóstico en 30 min, fix en 2 hrs
Actualizaciones: Cada 30 minutos en #incident-payment

Gestionando Impacto en el Sprint

Cuando el Buffer se Excede

Protocolo Buffer Excedido:

Situación: 20 pts de interrupciones, 15 pts de buffer

Opciones:
1. Extender trabajo del sprint → Riesgo de burnout, problemas de calidad
2. Eliminar items de menor prioridad → Mantener sostenibilidad
3. Solicitar ayuda adicional → Si está disponible
4. Negociar scope → Reducir scope de interrupción si es posible

Framework de Decisión:
├── ¿Podemos reducir el scope de la interrupción? → Intentar primero
├── ¿Es sostenible el overtime (raro)? → Solo corto plazo
├── ¿Qué podemos eliminar? → Discutir con PO
└── ¿Necesitamos ayuda? → Escalar a management

Comunicación a Stakeholders:
"Recibimos 33% más solicitudes urgentes de lo planificado.
Para mantener la calidad, diferimos Feature E al 
próximo sprint. Todos los items urgentes serán resueltos."

Ajustes del Sprint

Reunión de Ajuste Mid-Sprint:

Cuándo: Buffer excedido por 50%+
Quién: Scrum Master, Product Owner, Team Lead

Agenda:
1. Revisar volumen e impacto de interrupciones
2. Evaluar capacidad restante del sprint
3. Decidir qué diferir
4. Comunicar a stakeholders
5. Documentar para retrospectiva

Ejemplo de Decisión:
Corrección Mid-Sprint Sprint 19:
├── Compromiso original: 75 pts
├── Interrupciones recibidas: 22 pts (sobre 15 pts de buffer)
├── Capacidad ajustada: 75 - 7 = 68 pts
├── Diferido: Feature E (8 pts) → Sprint 20
└── Nuevo compromiso: 67 pts (alcanzable)

Notificación a stakeholders enviada ✓

Previniendo Falsas Urgencias

Validación de Urgencia

Antes de Aceptar P0/P1:

Checklist de Validación:
□ ¿Está producción realmente impactada?
□ ¿Cuántos usuarios afectados?
□ ¿Cuál es el impacto de negocio ($$)?
□ ¿Hay workaround?
□ ¿Puede esperar hasta mañana?
□ ¿Quién aprobó la prioridad?

Red Flags (probablemente no es urgente):
├── "El cliente está molesto" (sin impacto en producción)
├── "Prometimos esta feature" (no urgente, mala planificación)
├── "Ha estado roto por semanas" (no súbitamente urgente)
├── "Lo necesito para un demo" (urgencia personal, no de negocio)
└── Sin aprobación de manager en la prioridad

Respuesta:
"Entiendo que esto es importante. Basado en nuestros 
criterios, esto es P2 (Medio). Será abordado dentro 
de este sprint. Si crees que es realmente P0/P1, 
por favor obtén aprobación del VP."

Rastreando Patrones de Urgencia

Reporte Mensual de Interrupciones:

Total Interrupciones: 24
Por Prioridad:
├── P0 Crítico: 2 (8%)
├── P1 Alto: 6 (25%)
├── P2 Medio: 10 (42%)
└── P3 Bajo: 6 (25%) ← No deberían ser interrupciones

Por Fuente:
├── Reportes de clientes: 10 (42%)
├── Solicitudes internas: 8 (33%)
├── Alertas de monitoreo: 4 (17%)
└── Escalaciones de ventas: 2 (8%)

Por Categoría:
├── Bugs: 12 (50%)
├── Solicitudes de features: 6 (25%)
├── Preguntas de soporte: 4 (17%)
└── Seguridad: 2 (8%)

Insights:
├── 25% de solicitudes "urgentes" no eran urgentes
├── 50% son bugs → Necesita mejor QA
├── El mismo sistema causó 4 incidentes → Necesita refactor

Acciones:
├── Ajustar criterios de aceptación de P3
├── Invertir en estabilidad del sistema de pagos
└── Agregar monitoreo para top categorías de incidentes

Integración con Standup del Equipo

Estado de Interrupciones en Standup

Standup Diario con Interrupciones:

@alice (Manejadora de Interrupciones):
"Manejando: 2 interrupciones activas
- P1 Bug de pago: 60% hecho, ETA 2pm
- P2 Issue de export: En cola, comenzando después de P1
Buffer usado: 8/15 puntos
Estado del buffer: Saludable ✓"

@bob:
"Feature A: En camino, sin bloqueadores
No tomando interrupciones esta semana"

@carol:
"Feature B: En review
Heads up: Podría necesitar ayuda si llegan más P1s"

Scrum Master nota:
├── Buffer saludable, sprint en camino
├── Vigilar progreso de bug de pago
└── Carol marcada como respaldo si es necesario

Retrospectiva de Interrupciones

Retrospectiva del Sprint: Análisis de Interrupciones

Qué Pasó:
├── 4 interrupciones P1 (sobre el promedio)
├── 1 incidente P0 (outage de producción)
├── Buffer excedido por 5 puntos
├── 1 feature diferida al próximo sprint

Qué Salió Bien:
├── El rol de manejador de interrupciones protegió al equipo
├── P0 resuelto en 45 minutos
├── La escalación clara funcionó
└── Los stakeholders entendieron el diferimiento

Qué Mejorar:
├── 2 P1s eran en realidad P2 (sobre-escalados)
├── Sin runbook para issues de pago → Crear uno
├── El monitoreo no detectó el issue temprano → Mejorar
└── El buffer era muy pequeño → Aumentar a 18 pts

Items de Acción:
├── [ ] Crear runbook del sistema de pagos
├── [ ] Agregar monitoreo para gateway de pago
├── [ ] Revisar criterios de urgencia con ventas
└── [ ] Aumentar buffer a 18 pts próximo sprint

Mejores Prácticas

Para Equipos

Proteger el buffer — No sobre-comprometer trabajo planificado
Rotar justamente — Compartir la carga de interrupciones
Documentar interrupciones — Los patrones informan mejoras
Decir no apropiadamente — No todo es urgente
Mejorar sistemas — Reducir interrupciones futuras