Los cambios a un Sprint.
Si hay una solicitud de cambio que puede tener un impacto significativo sobre un Sprint en progreso, el Product Owner, después de consultar con stakeholders relevantes, decide si el cambio puede esperar hasta el próximo Sprint o si representa una situación urgente que puede requerir finalizar o cancelar el Sprint actual y comenzar uno nuevo.
El marco de Scrum especifica claramente que el alcance de un Sprint no se puede cambiar una vez que comienza el Sprint. Si el cambio requerido es tan importante que los resultados del Sprint no tendrían ningún valor sin él, entonces el Sprint debe ser terminado. Si no, entonces el cambio se incorpora en un Sprint más adelante (como se muestra en la Imagen).
Sólo hay una excepción a esta regla de no modificar el alcance de un Sprint una vez que ha comenzado. Si el Equipo Scrum determina que se ha sobrestimado en gran medida el esfuerzo durante el Sprint y no tiene capacidad para poner en práctica Historias de Usuarios adicionales, el equipo le puede preguntarle al Product Owner cuáles Historias de Usuarios se han de incorporar en el Sprint actual.
Al bloquear el alcance de cada Sprint, el equipo es capaz de optimizar y administrar con eficiencia su trabajo y esfuerzo. Un beneficio adicional es que el equipo no tiene que preocuparse por la gestión de los cambios una vez que comienzan a trabajar en un Sprint. Esta es una gran ventaja del marco de Scrum en comparación con la gestión tradicional de Proyectos.
En la gestión tradicional de Proyectos, los cambios pueden ser solicitados y aprobados en cualquier momento durante el ciclo de vida del Proyecto. Esto a menudo crea confusión entre los miembros del equipo del Proyecto, disminuye la motivación del equipo debido a la discontinuidad, y da lugar a una falta de concentración y el equipo tiene la sensación de que “nunca se acaba nada”. Por otro lado, en los Proyectos Scrum, los cambios no se permiten una vez que se inicia un Sprint. Esto asegura que en cada Sprint, el equipo complete entregables y que las tareas se lleven a cabo.
Por otra parte, el negocio reconoce los beneficios tangibles de los Entregables que están potencialmente listos para la entrega al final de cada Sprint.
Además, como el Product Owner y los stakeholders son conscientes de que los cambios no se permiten una vez que el Sprint comienza, y un Sprint dura entre 1 y 6 semanas, ellos definen y priorizan las necesidades durante los procesos adecuados de Crear Épica(s), Crear la Lista de Pendientes del Product Backlog, y la priorización de los elementos del Product Backlog.