¿A qué nivel debe priorizar el trabajo el propietario del producto?

Scrum es más efectivo cuando hay un backlog y un Product Owner para un equipo de entrega.

El backlog está diseñado para que el trabajo que está a punto de comenzar se defina a nivel de historia de usuario , lo cual es conveniente para que trabaje el equipo de entrega. Pero la acumulación también puede contener trabajo planificado para el que faltan varias semanas o incluso meses. Este trabajo a veces se puede definir de manera bastante aproximada y se representa por 'epopeyas' o 'temas' . Estos son probablemente lo más parecido en Scrum al 'Proyecto A', 'Proyecto B' y 'Proyecto C' que menciona.

La idea es que el Dueño del Producto esté refinando continuamente el backlog. Descomponen el trabajo definido a grandes rasgos en historias de usuarios más concretas de manera oportuna. De modo que el trabajo que está a punto de comenzar está bien definido, pero el trabajo futuro puede ser menos claro.

Aunque el propietario del producto es responsable del backlog, eso no significa que sea la única persona que trabaja en él. Es bastante común que el Scrum Master y el equipo de entrega se sienten con el Product Owner y lo ayuden con la tarea de dividir el trabajo futuro en historias de usuarios. Esto es particularmente común cuando el Product Owner no tiene mucha experiencia en el rol.

Mi primera recomendación sería sugerir que la persona que actualmente se encuentra en el rol de Propietario del Producto obtenga algún tipo de capacitación. La certificación de propietario del producto es ideal y, por lo general, solo requiere un par de días de capacitación.

En segundo lugar, haga que Scrum Master y el equipo trabajen con el Product Owner para ayudarlos a dividir el trabajo mal definido en requisitos con los que el equipo pueda trabajar. Le sugiero que haga esto como parte de las reuniones de refinamiento de tareas pendientes que ocurren con bastante frecuencia. Es posible que descubras que una vez que hayas hecho esto unas cuantas veces, el Product Owner comenzará a comprender el concepto y luego hará una gran parte del refinamiento por sí mismo.

Parece que tienes un problema con el objetivo de Sprint coherente .

No sé cómo utiliza el equipo la acumulación de productos, pero debe enfatizar al PO que cuanto más coherente sea el contenido del sprint, más eficiente será el trabajo del equipo. Si cada miembro trabaja en su propio elemento, no es realmente Scrum (me refiero al significado original de Rugby ). Para aprovechar Scrum (marco), todo el equipo debe tener el objetivo común del sprint de aumentar la colaboración y la autoorganización.

Una cosa más. En la publicación mencionas:

Supuestamente, un gran dueño de producto organizará los artículos en orden de prioridad para maximizar la cantidad de trabajo que puede hacer el equipo.

El propietario del producto está aquí para maximizar el ROI (retorno de la inversión) del proyecto, no la cantidad de trabajo. PO debe ordenar la cartera de productos para que el proyecto entregue el máximo valor posible en cada iteración (para que el equipo trabaje primero en los elementos más importantes).

Según entiendo por lo que ha proporcionado hasta ahora, su síntoma es:

siempre hay elementos competitivos para el tiempo de desarrollo

Esto es en sí mismo un desafío muy normal de la vida (desarrollador de software), que el propietario del producto es responsable de cuidar. Hasta ahora parece estar en el camino correcto, solo que el problema parece ser que tiene múltiples proyectos para un equipo, con personas dedicadas en el equipo para cada proyecto. Ahora, en caso de que los distintos proyectos no tengan ninguna interdependencia, recomendaría dividir los equipos en equipos más pequeños, cada uno compuesto por el equipo de desarrollo que trabaja en una cartera de productos para uno de los proyectos que tiene.

Si dividir el equipo no es una opción (debido a las dependencias), debe incluir todos los proyectos en una cartera de pedidos para el equipo que tiene . Luego, nuevamente depende de la OP decidir sobre las prioridades dentro de ese trabajo pendiente. Y sí, es normal que esto sea un desafío para la OP. En general, puede tener un trabajo pendiente para varios equipos, pero no puede tener varios trabajos pendientes para un equipo.

¿Cuál es una forma efectiva de corregir el estilo de gestión del Product Owner y Stake Holder?

No ha dicho por qué quiere hacer esto, considere qué problema se está creando como resultado de este estilo de gestión, esa será su palanca para corregir.

Habiendo dicho eso, la clave para recordar es que, si bien la OP es responsable de la acumulación, no es la única persona que tiene una entrada. Todo el equipo de scrum debe proporcionar información que el PO tenga en cuenta. ¿Está pasando eso aquí? ¿La OP tiene una certificación PSM?

Como dijo otro afeitado, realmente no funciona tener un solo scrum para trabajar en varios proyectos, considere dividir el equipo. Aprecio que esta es una empresa pequeña pero, y nuevamente, la capacitación podría ayudar aquí, pero scrum está configurado de esa manera por una razón. Da prioridad al proyecto que lo necesita, luego pasa al siguiente proyecto.

En cuanto a la acumulación, la OP debe organizarla para obtener el mejor retorno de la inversión, no ha dicho si eso está sucediendo aquí, porque si no es así, entonces tal vez pueda demostrarles cómo podría funcionar mejor proporcionando; una cartera de pedidos mejor estructurada, algo de formación, etc.

Para resumir, parece que no tiene un scrum, sino que está utilizando los títulos proporcionados por scrum para continuar con la práctica estándar. Esto puede deberse a la falta de capacitación; sin embargo, también se debe a la falta de estandarización entre las organizaciones sobre los conceptos y la entrega ágiles.

Me parece que toda la organización, desde la parte superior hasta el equipo de scrum, necesita aprender el concepto de tareas y autoorganización.

No está fuera de lugar que una organización tenga varios proyectos ejecutándose al mismo tiempo. Sin embargo, se debe dar prioridad a dicho proyecto de acuerdo con su creación de valor y urgencia para la organización.

No es saludable que el PO extraiga de una fuente del equipo de desarrollo y lo asigne a otro proyecto en curso. Lo que se podría hacer mejor aquí es desde el PO dividir el equipo de desarrollo en la cantidad de proyectos que se ejecutan simultáneamente y asignar cada equipo de desarrollo a un producto para que los miembros del equipo puedan comprender sus entregas. El Proyecto A, por ejemplo, debe tener su propia cartera de productos y los PBI deben refinarse y trasladarse a un sprint priorizado en función del acuerdo colectivo de todo el equipo de scrum y el valor que dichos elementos aportan. Las ruedas también deben reinventarse para otros proyectos.

También vale la pena señalar que un Scrum Master solo puede administrar un equipo Scrum a la vez, microadministrar varios equipos dentro de una organización no es una buena idea, en cambio, el equipo Scrum debe terminar un proyecto antes de elegir comenzar otro.

Tiene un problema... el propietario del producto no es un propietario del producto real, por lo que no sabe nada acerca de la agilidad, por lo que scrum nunca funcionará de esa manera, a menos que encuentre un propietario del producto adecuado.

Como dice la guía de Scrum, la dirección, stakeholders en este caso, ayudan a la empresa a implementar scrum, pero no son parte de ella, más en este caso, cuando la persona no tiene ni idea de agilidad.

La mentalidad detrás de lo que describe no es para Scrum, en cambio, use Kanban y comenzará a ver los beneficios. La empresa en la que trabaja no se centra en algo específico, como el cumplimiento de scrum (objetivos)... su objetivo es oportunista y probablemente se basa puramente en los ingresos, por lo que atraen a los desarrolladores donde sea necesario para lograr resultados comerciales... Scrum no es destinado a estas situaciones me temo.

Lo estás diciendo... les importa el WIP y eso es una cosa de Kanban. Y es posible que vean que se necesita algo porque no han oído hablar de eso en mucho tiempo... ¡así que Kanban otra vez!

Deja de hacer Scrum y pásate a Kanban... la vida de todos será más fácil.