En Scrum, durante un Sprint (iteación) se congelan todos los requisitos relacionados con el Sprint en proceso. Ningún cambio se introduce hasta que termine el Sprint, a menos que el cambio se considere tan significativo como para parar el Sprint.  En el caso de un cambio urgente, el Sprint se suspende y el equipo se reúne para planificar uno nuevo. Esta es la manera en que Scrum acepta cambios sin crear el problema de cambiar las fechas de entrega.

Si existe una solicitud de cambio que puede tener un impacto significativo en un Sprint en progreso, el Propietario del Producto (Product Owner), después de consultar con los interesados relevantes, decide qué cambio puede esperar hasta el siguiente Sprint o cuál representa una situación urgente en la cual se puede requerir la terminación del Sprint actual e iniciar uno nuevo. El marco Scrum claramente especifica que el alcance del Sprint no puede cambiarse una vez que el Sprint inicia. Si el cambio requerido es tan importante que los resultados del Sprint pueden no tener valor sin él, entonces el Sprint debería terminar. Si no es así, el cambio se incorpora en un Sprint posterior. Esto se ilustra arriba con el diagram.

Solo existe una excepción a esta regla acerca de no cambiar el alcance de un Sprint una vez que este ha iniciado. Si el Equipo Scrum determina que se ha sobrestimado mucho el esfuerzo para el Sprint y cuenta con capacidad de reserva para implementar una Historia de Usuarios adicional, el equipo puede preguntar al Propietario del Producto cuál(es) Historia(s) de Usuario adicional(es) se puede incluir en el Sprint actual. Al bloquear el alcance de cada Sprint, el equipo es capaz de optimizar eficientemente y gestionar su trabajo y esfuerzo.

Un beneficio adicional es que el equipo no debe preocuparse acerca de gestionar cambios una vez que empiezan a trabajar en el Sprint. Esta es una gran ventaja del marco Scrum comparado con la dirección de proyectos tradicional. En la dirección de proyectos tradicional, se puede solicitar y aprobar cambios en cualquier momento durante el ciclo de vida del proyecto. Esta situación generalmente produce confusión en los miembros del equipo, reduce la motivación debido a la falta de continuidad, y deriva en falta de enfoque y la sensación para el equipo de que “nunca, nada se completa”.

Por otro lado, en los proyectos Scrum, no se permite cambios una vez iniciado el Sprint. Esto asegura que en cada Sprint el equipo complete los entregables y las tareas. Además, los negocios reconocen los beneficios tangibles de los Entregables Potencialmente Liberables (PSP) al final de cada Sprint.

Finalmente, dado que el Propietario del Producto y los Interesados están conscientes de que no se permite cambios una vez que el Sprint comienza y que el Sprint dura entre 1 y 6 semanas, ellos definen y priorizan sus requisitos.

Autor: SCRUMstudy

Traducción: Adela Vega, TSPM, SMC, SDC

Adaptación: Enrique Ledesma M.Sc., PMP, STC, SPOC, SMC, SDC