¿Cómo manejas una solicitud para cambiar el alcance a mitad de un Sprint?

Question

Accepted Answer

El valor por defecto en Scrum es **proteger el Sprint Goal**: no se deben agregar cambios que lo pongan en peligro. Pero Scrum no es rígido — el alcance puede *renegociarse con el Product Owner*, y un cambio verdaderamente urgente puede manejarse, con compensaciones explícitas.

## Un marco de decisión

```text
1. Does the new request threaten the Sprint Goal?
     NO  → can it wait for the next Sprint? Usually yes → backlog it.
     YES → talk to the Product Owner about trade-offs.
2. Is it a genuine emergency (prod down, legal, security)?
     YES → the PO may cancel/replace work; something must drop.
3. Make the trade-off visible: pulling X in means Y comes out.
```

## Ejemplo concreto

A mitad del Sprint, ventas quiere un "pequeño" reporte nuevo. El Scrum Master ayuda al equipo y al Product Owner a ver que no es urgente, así que va a la parte superior del backlog del próximo Sprint en lugar de interrumpir el objetivo actual.

## Errores comunes

- Absorber silenciosamente trabajo adicional, destruyendo el Sprint Goal y ocultándolo.
- Decir un "no" categórico sin una salida — el Product Owner siempre puede renegociar.
- Permitir que cada stakeholder inyecte trabajo directamente, evitando al Product Owner.

## Por qué es importante

Proteger el Sprint Goal es lo que hace que Scrum sea predecible; la inyección constante convierte los Sprints en listas de tareas caóticas.

Manejar el cambio a través del Product Owner con compensaciones explícitas mantiene al equipo enfocado mientras permanece receptivo a las emergencias reales.