Cambios a un sprint

Si hay una solicitud de cambio que puede tener un impacto considerable sobre un sprint en curso, 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 pueda requerir finalizar el sprint actual y comenzar uno nuevo.

El framework de Scrum especifica claramente que el alcance de un sprint no puede cambiarse una vez que este comience. Si el cambio requerido es tan importante que los resultados del sprint no tendrían ningún valor sin él, entonces el sprint debe terminarse. De lo contrario, entonces el cambio se incorpora más adelante en un sprint (como se muestra en la figura 6-6).

Sólo hay una excepción a la 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 usuario adicionales, el equipo puede preguntarle al Product Owner cuáles historias de usuario deben incorporarse al 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 empieza a trabajar en un sprint. Esta es una gran ventaja del framework de Scrum en comparación a la gestión tradicional de proyectos.

En la gestión tradicional de proyectos, los cambios pueden solicitarse y aprobarse en cualquier momento durante el ciclo de vida del proyecto. Esto a menudo causa confusión entre los miembros del equipo del proyecto, disminuye la motivación del equipo debido a la discontinuidad, da lugar a una falta de concentración y el equipo tiene la sensación de que “nunca se termina nada”. En cambio, en los proyectos Scrum, los cambios no se permiten una vez que se inicia un sprint. Esto garantiza 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 están conscientes de que los cambios no se permiten una vez que inicia el sprint, y que un sprint dura entre 1 y 6 semanas; definen y priorizan las necesidades durante los procesos adecuados de Crear épica(s), Crear el Backlog Priorizado del Producto y el Refinar el Backlog Priorizado del Producto.

6.5.1.1 Impacto del cambio esperado en la duración del sprint

Dado que los cambios no están permitidos durante un sprint, el impacto y la frecuencia de los cambios previstos pueden tener un impacto en la decisión relacionada a la duración del sprint cuando esta se determina durante el proceso de Realizar la planificación del lanzamiento.

Si los requisitos del proyecto son generalmente estables y no se esperan grandes cambios en un futuro próximo, la duración de un sprint se puede ajustar para que sea más larga, de 4 a 6 semanas. Esto les proporciona estabilidad a los miembros del Equipo Scrum para trabajar en los requisitos del Backlog Priorizado del Producto durante largos periodos de tiempo sin tener que pasar por los procesos de Crear historias de usuario, Estimar historias de usuario y Comprometer historias de usuario, Identificar tareas, Estimar tareas y otros procesos relacionados que se llevan a cabo para cada sprint.

Sin embargo, si los requisitos del proyecto no están muy bien definidos, o si se esperan cambios considerables en un futuro inmediato, la duración del sprint puede ser relativamente corta, de 1 a 3 semanas. Esto les brinda estabilidad a los miembros del Equipo Scrum para trabajar en sprints más cortos y entregar resultados, los que se pueden evaluar por el Product Owner y los stakeholders al final del sprint. Esto también proporciona la flexibilidad suficiente para que puedan aclarar los requisitos y realizar cambios en el Backlog Priorizado del Producto al final de cada sprint.

6

Para obtener los máximos beneficios de un proyecto Scrum, siempre se recomienda mantener el sprint bajo

un time-box de cuatro semanas, a menos que existan proyectos con requisitos muy estables, donde los sprints pueden extenderse hasta seis semanas.

La figura 6-7 muestra el impacto del cambio esperado en la duración del sprint.

Figura 6-7: Impacto del cambio esperado en la duración del sprint

Sin embargo, es importante tener en cuenta que el cambio esperado no es el único factor que se utiliza para determinar la duración del sprint. Otros factores que también deben tomarse en cuenta son:

• El tiempo real para realizar su trabajo (si el proyecto o entorno corporativo necesita un tiempo específico para realizar tareas de forma, eso podría determinar la duración del sprint)

• _{La fecha prevista para su lanzamiento (la duración del sprint debe tener en cuenta las fechas de} lanzamiento para el producto o el servicio en general)

• Cualquier otro factor que determine el Product Owner o el Scrum Master que deben tenerse en cuenta al determinar la duración del sprint

Es importante tener en cuenta que el cambio en la duración del sprint no debe decidirse a la ligera o de manera periódica (por ejemplo, no es recomendable tener un sprint de tres semanas, luego uno de dos semanas y el siguiente de cuatro semanas, etc.) De preferencia, la duración del sprint debe ser consistente. Uno de los mayores impactos del cambio de la duración del sprint es que causa un restablecimiento en todo el seguimiento a nivel de proyecto. Las velocidades anteriores pueden llegar a ser inútiles para la previsión y la planificación de los futuros sprints. Sin una velocidad precisa (que es una medida primaria en cualquier

proyecto Scrum), el Equipo Scrum no puede medir la eficacia o elegir adecuadamente el número de historias para asumir la planificación del próximo sprint. Por lo tanto, una vez que la duración del sprint se decide, de preferencia debe permanecer constante durante toda la duración del proyecto o a través de múltiples ciclos de sprint.

6.5.1.2 Gestión de cambios mediante el refinamiento del Backlog Priorizado del Producto

Un típico Backlog Priorizado del Producto incluirá todas las historias de usuarios, sus estimaciones de tiempo (incluyendo las estimaciones revisadas) y el estado de las necesidades de mayor prioridad. También se incorporan historias de usuario nuevas o revisadas que resultaron de cambios en los requerimientos de negocio, pedidos de los clientes, condiciones externas del mercado y/o lecciones aprendidas en sprints anteriores.

Una de las responsabilidades principales de los Product Owners es preparar el Backlog Priorizado del Producto para garantizar que los requisitos priorizados en dicho backlog se incluyan en los próximos dos o tres sprints, y se refinen en acuerdo con las historias de usuario. Se recomienda que el Product Owner dedique una cantidad considerable de tiempo en cada sprint para refinar el backlog. El Product Owner es responsable de añadir y modificar elementos a dicho backlog en respuesta a los cambios, así como de proporcionar historias de usuario más detalladas que se utilizarán en el próximo sprint.

Este refinamiento o grooming ayuda a asegurar que la refinación de los requisitos y sus historias de usuario se hagan mucho antes de la reunión de planificación del sprint, a fin de que el equipo tenga un conjunto de historias muy bien analizadas y claramente definidas que puedan dividirse fácilmente en tareas y, posteriormente estimadas. Con base en las lecciones aprendidas del sprint actual, puede haber cambios en los requisitos, o bien una priorización nueva que pueda incorporarse fácilmente en sprints posteriores. Este refinamiento apoya y mejora la flexibilidad del modelo Scrum mediante la incorporación de los últimos avances técnicos y de negocio en futuros sprints.

La reunión de revisión del Backlog Priorizado del Producto es una reunión formal durante el proceso de refinamiento de dicho backlog, que ayuda al Equipo Scrum a repasar y lograr el consenso sobre el grooming del Backlog Priorizado del Producto. Sin embargo, además de la reunión de revisión del Backlog Priorizado del Producto, su refinamiento debe darse durante todo el proyecto y puede incluir situaciones en las que el Product Owner escriba nuevas historias de usuarios o vuelva a priorizar las historias de usuario en el Backlog Priorizado del Producto vigente, y los miembros del Equipo Scrum o stakeholders ofrezcan sugerencias sobre las nuevas historias al Product Owner, y así sucesivamente.

Es importante tener en cuenta que cualquier elemento del Backlog Priorizado del Producto está siempre abierto para la re-estimación hasta que el Sprint Backlog sea finalizado en el proceso de Crear el Sprint Backlog. Después de ello, los cambios se podrán seguir haciendo inclusive hasta momentos antes de la reunión de planificación del sprint, si es necesario.

6

6.5.1.2.1 Reunión eficaz de revisión del Backlog Priorizado del Producto (o Sesión de refinamiento del Backlog Priorizado del Producto)

El Product Owner es quien está encargado de que se lleve a cabo una reunión de revisión del Backlog Priorizado del Producto durante el proceso de Refinar el Backlog Priorizado del Producto. Es importante que el Product Owner establezca los objetivos y que de preferencia desarrolle un orden del día antes de iniciar la reunión. Sin esto, la sesión no tendría estructura y podría resultar improductiva. También es importante limitar el número de stakeholders que participan en la reunión. El tener demasiados participantes tiende a disminuir la eficiencia general de la reunión. El Product Owner debe invitar sólo a los stakeholders cuyas votaciones se requieren para la sesión de la preparación. Se deben incluir todos los miembros del Equipo Scrum debido a que su opinión es valiosa para el trabajo que se realiza y los problemas que se encontraron. Si los resultados de la sesión de preparación o cuidado resultan en nueva priorización o cambio en el Backlog Priorizado del Producto, es importante que el equipo esté de acuerdo con esos cambios.

Una eficaz sesión de grooming debe resultar en los elementos claramente definidos en el Backlog Priorizado del Producto para que el Equipo Scrum entienda los requisitos del cliente. Esto también ayuda a que el equipo se familiarice con todas las historias de usuario en caso de que una o más de ellas sean incluidas en un sprint a corto plazo. También pueden tratarse los criterios de aceptación y de terminado durante las sesiones de preparación.

En Scrum los ejercicios de refinación no tienen a un time-box. El refinamiento del Backlog Priorizado del Producto es una actividad continua del Product Owner.

6.5.1.3 Gestión de cambios durante la demostración y validación del sprint

Aunque el Product Owner tiene la última palabra sobre los elementos del Backlog Priorizado del Producto y decide si se aceptan o rechazan las historias de usuario (correspondientes a las solicitudes de cambio aprobadas) presentadas durante el proceso de Demostrar y validar el sprint, es la responsabilidad del Scrum Master garantizar que los requisitos y criterios de aceptación no se modifiquen durante la reunión de revisión del sprint de las historias de usuario completadas en el sprint actual. Esto evita el rechazo de futuras historias de usuario basado en el hecho de que no cumplen los requisitos recién cambiados. Si los requisitos se debieran cambiar, cualquier elemento del Backlog Priorizado del Producto correspondiente debe revisarse para adaptarse a los requisitos modificados en un sprint futuro.

In document CUERPO DE CONOCIMIENTO DE SCRUM (Guía SBOK ) (página 136-141)