Escenario: Tenemos arquitectos que escriben especificaciones y criterios de aceptación. Los especialistas comerciales y el propietario del producto no brindan ninguna especificación/lógica comercial documentada, por lo que los arquitectos escriben los criterios de aceptación y los revisan con el especialista comercial y el propietario del producto en una reunión.
Problema: mientras el PO estaba probando la tarea (Prueba del propietario del producto mencionada en esta publicación: Publicación sobre la prueba del propietario del producto, encontró un escenario que no funciona. Pero hemos leído los criterios de aceptación y ese escenario nunca se mencionó y ella quiere fallar la tarea.
Pregunta: ¿Puede un PO fallar en una tarea porque el escenario no se mencionó en los criterios de aceptación?
¡Yo diría que no! porque eso puede causar la fluencia del alcance.
Asunto:
El PO/especialista comercial debe redactar la lógica comercial/los requisitos para que cuando un arquitecto trabaje en las especificaciones/criterios de aceptación, pueda atender todos los escenarios.
No se desvíe de los criterios de aceptación porque pueden agregar todo tipo de escenarios o solicitudes después del desarrollo.
No tienes un solo problema, tienes muchos. Aparte de la falta de un equipo multifuncional que colabore plenamente, los dos problemas de proceso más grandes parecen ser:
A menos que arregles ambos problemas, no estás haciendo Scrum. Más importante aún, el equipo Scrum seguirá siendo disfuncional mientras el propietario del producto y el equipo de desarrollo sigan en disputa en lugar de colaborar estrechamente entre sí.
Todo el Equipo Scrum (no solo el Dueño del Producto) necesita ser reeducado sobre cómo funciona realmente el desarrollo iterativo. En Scrum, cada Sprint tiene un objetivo único y coherente (el Sprint Goal) en el que todo el equipo trabaja en conjunto para completarlo. El propietario del producto prioriza el trabajo, el equipo de desarrollo lo selecciona y lo planifica para el Sprint, y luego se demuestra el trabajo completado a las partes interesadas en la revisión del Sprint. La Revisión del Sprint también puede ser un lugar para discutir por qué no se cumplió el Objetivo del Sprint (si no se cumplió), y para recopilar comentarios sobre el producto o discutir los próximos pasos y las prioridades futuras con las partes interesadas.
Durante la Planificación del Sprint, el Equipo Scrum colabora en:
Si el Equipo Scrum hizo su trabajo durante el Refinamiento del Backlog y trabaja en conjunto correctamente durante la Planificación del Sprint, entonces no hay lugar para que un Propietario del Producto "apruebe" o "suspenda" el trabajo. Simplemente no es parte del marco, ni es una práctica aceptable.
Lo que realmente sucede aquí es que el Product Owner, las partes interesadas o los miembros del equipo están descubriendo un nuevo trabajo que no se había identificado previamente en Backlog Refinement o Sprint Planning. ¡Genial! Lo que debería suceder a continuación es que el trabajo recién descubierto se agregue al Product Backlog, de modo que el Product Owner pueda refinarlo y priorizarlo como trabajo futuro para algún otro Sprint.
En el desarrollo iterativo, el "desplazamiento del alcance" no ocurre porque el trabajo recién descubierto o los nuevos requisitos no pueden modificar fundamentalmente la iteración del cuadro de tiempo actual. En cambio, se convierten en agua para el molino a medida que el producto continúa creciendo gradualmente con el tiempo.
La única excepción es cuando se descubre algo que pone en riesgo el Sprint Goal actual. Si el objetivo del Sprint no se puede cumplir a menos que el equipo vuelva a la mesa de dibujo, entonces el propietario del producto debe declarar una terminación anticipada de todo el Sprint y regresar a la planificación del Sprint. Esto tiene un costo visible para el proyecto (visible es bueno; costo, no tanto), por lo que generalmente es mejor tratar el trabajo nuevo como trabajo futuro a menos que el impacto sea lo suficientemente alto como para justificar el costo. Esa es la decisión del Product Owner, y tomar esa decisión es parte fundamental de su trabajo.
Más allá de eso, el trabajo se hace o no se hace . Si se hizo de acuerdo con el plan del equipo, se completó de acuerdo con la Definición de Hecho y se demostró dentro del cuadro de tiempo actual, entonces no hay oportunidad de "fallar" o "rechazar" el trabajo. El equipo creó aquello en lo que todos colaboraron y acordaron que era necesario, incluido el propietario del producto.
Si luego resulta que el Equipo Scrum creó algo incorrecto , entonces se trata de un problema de colaboración o comunicación que debe abordarse en la Retrospectiva del Sprint. Es probable que solucionar el problema del proceso implique una colaboración más estrecha con las partes interesadas que no pertenecen al equipo, tanto por parte del propietario del producto como de los miembros del equipo de desarrollo.
Por otro lado, si el equipo simplemente descubrió un nuevo trabajo o la necesidad de mejoras adicionales, ¡eso es genial! Eso es lo que se supone que deben hacer los marcos ágiles. El nuevo trabajo se puede priorizar y programar como cualquier otro trabajo dentro del marco.
Todd A. Jacobs
Ruán