¿Un Propietario de Producto se somete a Control de Cambios antes de reorganizar la Lista de Producto?

El control de cambios no es una herramienta de alcance ágil

Si él / ella desea cambiar el alcance agregando / eliminando / volviendo a priorizar el Backlog, el PO debe enviar una Solicitud de cambio formal / IOCA antes de tomar un Cambio aprobado para la consideración de Scrum Master para la planificación.

Esta es la antítesis de la agilidad. Si bien Scrum funciona bien en entornos que requieren un control de cambios formal, el proceso de control de cambios generalmente está destinado a salvaguardar la integridad del entorno de producción en lugar de mantener sacrosanta la Lista de Producto.

Análisis y Recomendaciones

Sospecho que el requisito de "control de cambios" es realmente un intento de las partes interesadas o del comité directivo de controlar el alcance o el presupuesto del proyecto. Si ese es el caso, el Scrum Master necesita educar mejor a la organización sobre cómo funciona realmente el desarrollo iterativo y trabajar con el equipo para garantizar que el producto esté siempre en un estado liberable al final de cada iteración.

Las partes interesadas, a través del propietario del producto, pueden agregar o eliminar elementos del Product Backlog en cualquier momento . Lo único que no pueden hacer es cambiar las historias dentro del Sprint actual a menos que el propietario del producto solicite una finalización anticipada y un regreso a Sprint Planning.

Técnicamente, no hay nada en Scrum que requiera o impida que las partes interesadas apliquen el control de cambios en los requisitos que pasan al propietario del producto. La forma en que el propietario del producto interactúa con las partes interesadas es una externalidad del marco Scrum, que simplemente exige que el propietario del producto esté a cargo del contenido y el pedido de la cartera de productos.

Sin embargo, tal mariscal de campo de peso pesado es un "olor de proyecto" significativo que generalmente indica que la organización no ha adoptado el modelo de desarrollo iterativo y probablemente no entiende cómo usar de manera efectiva los controles de proceso integrados del marco. Educar a la organización sobre el marco Scrum es el trabajo del Scrum Master, y administrar de manera efectiva a las partes interesadas es el trabajo del propietario del producto.

Reconsidere la elección del marco

La educación parece ser el ingrediente que falta aquí. Por supuesto, Scrum tampoco es una bala de plata, no es adecuado para todas las organizaciones y simplemente puede ser una mala opción para una organización de mando y control. Una buena cascada no tiene más probabilidades de fallar que Scrum implementado incorrectamente, por lo que también puede valer la pena reconsiderar si Scrum es el marco adecuado para la organización.

Diferentes marcos pueden encajar mejor. ¡Su millaje ciertamente puede variar!

Nunca he hecho esto y sería un gran anti-patrón porque:

1. Estas desalentando el cambio
2. Estás excluyendo al PO del equipo, al menos indirectamente

Habiendo dicho eso, esto ha sucedido muchas veces. Al final, tiene que tratarse de la relevancia del objetivo del sprint para el negocio. Si el PO tiene algo relevante para el objetivo, animo al equipo a decidir rápidamente qué cambios se deben realizar sin inflar la velocidad. Si es irrelevante, dejo que el PO decida si debemos detener el sprint y comenzar uno nuevo. El 100 % de las veces, el PO comprender la detención y el inicio de un nuevo sprint será mucho más costoso que agregar algunos "cambios urgentes".

Finalmente, no es raro que los equipos trabajen de manera tradicional (BDUF, Waterfall, etc.) mientras emplean prácticas ágiles particulares como el rol, los scrums diarios y los sprints. Esto no es Scrum, pero es mejor que no tener intervalos para "inspeccionar y adaptar". Sospecho que esto puede aplicarse a usted, por lo que puede ser necesario establecer barreras al cambio para que el proyecto siga avanzando y dentro del alcance.