Preparación de trabajos pendientes

Para hacer Sprint Planning, primero necesita un Product Backlog. Lo que tiene no es suficiente para actuar como un Product Backlog.

La Guía Scrum define un Product Backlog como "una lista ordenada de todo lo que se sabe que se necesita en el producto". Parece que tiene esto, pero los elementos de la cartera de productos son más que requisitos breves. Los elementos del Product Backlog se ordenan en el Product Backlog, considerando la prioridad y las dependencias. El equipo de desarrollo y el propietario del producto también refinan continuamente los elementos de la cartera de productos para agregar detalles, estimaciones y mejorar el pedido. Una característica es que los elementos de mayor orden tienden a tener más detalles y estimaciones más precisas que los elementos de menor orden en la Lista de Producto.

Al observar lo que se conoce como Product Backlog en la pregunta, veo algunas cosas que se destacan. Los "elementos" no son muy claros: parecen ser declaraciones de requisitos simples que el equipo no ha perfeccionado. Esperaría una conversación entre el propietario del producto y el equipo de desarrollo para agregar detalles, y tal vez incluso descomponer los elementos en varios elementos más pequeños que se pueden diseñar y entregar de forma independiente; después del refinamiento, los elementos de la cartera de productos a menudo cumplen con los criterios INVEST . Tampoco esperaría que los elementos de la cartera de productos tengan una estimación hasta después de que tengan muchos más detalles que los que se muestran aquí. La asignación de elementos de la cartera de productos a los sprints no es algo que realiza el propietario del producto, sino que lo hace el equipo de desarrollo en Sprint Planning.

Lo que estás presentando es, en mi opinión, insuficiente para Sprint Planning. El refinamiento con el Equipo de Desarrollo debe ocurrir primero. Después del Refinamiento, el Equipo de Desarrollo tendrá suficiente información sobre los elementos en el Product Backlog para comenzar a tomar decisiones bien informadas sobre lo que podrán lograr en un Sprint. Con el tiempo, pueden incluir datos históricos para mejorar aún más su toma de decisiones.

Tienes mucha información superflua en tu pregunta. Si tiene una cartera de pedidos priorizada, podemos suponer que hacer el trabajo en el orden dado proporcionará el ROI más alto. Por lo tanto, a menos que el equipo tenga razones específicas para cambiar el orden, buscaría que tiraran del primer elemento, luego el segundo si encaja, luego el tercero, y así sucesivamente.

Ahora, esto se complica un poco con los objetivos de sprint y tratando de generar incrementos de valor en lugar de simplemente generar código, pero la base es siempre la misma.

Agregaré mi voz a la de Bart y Daniel, y daré un paso más: no utilizo el método MoSCOW en absoluto por la simple razón de eliminar la confusión que sientes. Mis equipos no tuvieron problemas y, de hecho, prefirieron obtener un orden de clasificación como el que describe Bart. Tengo PO que usan el método que les gusta para determinar el valor comercial para la clasificación, pero la categorización como Alto-Medio-Bajo ha causado más problemas de los que ha resuelto entre mis clientes.

Para cumplir con los comentarios sobre la calidad de sus requisitos, considere escribirlos todos como historias de usuario (o "casos de uso" a la antigua): "Como [usuario], quiero [función/acción específica], para que [propósito] ." La literatura sobre epopeyas generalmente las describe como historias de usuario, demasiado grandes para completarlas en un sprint. También capacito a mis clientes para que agreguen los Criterios de aceptación propuestos, la prueba que necesitará ver para aceptar la historia, generalmente en una sola oración (de alto nivel). Sin embargo, el lenguaje final tanto de la historia como de los criterios debe negociarse con el equipo durante la planificación del sprint, tanto para respetar su autogestión como para garantizar que obtienes lo que esperabas.

TL;RD

Un Product Backlog debe basarse principalmente en las prioridades específicas de la organización. Eso significa que "debe" generalmente debe ser más alto que los elementos "debería" o "podría". Sin embargo, los marcos como Scrum que se construyen alrededor de los objetivos de la iteración brindan libertad para incluir objetivos secundarios o metas amplias durante la planificación de la iteración.

Comprender la colaboración de backlog en Scrum

Se requiere un Product Backlog para ser ordenado. Por lo general, todo lo que sea opcional o de menor prioridad debe mantenerse por debajo de las características/funcionalidades requeridas hasta que dicho trabajo entre en el alcance por otras razones, como un cambio en las prioridades comerciales.

El Product Backlog puede contener datos auxiliares sobre el plan de lanzamiento ágil basado en el tiempo de entrega esperado , pero esto de ninguna manera proporciona una garantía o permite que el propietario del producto defina o controle los contenidos del Sprint Backlog.

El contenido y el formato del Product Backlog dependen del Dueño del Producto. No existe un requisito de marco para realizar estimaciones sobre la cartera de productos, pero los equipos que realizan regularmente el refinamiento de la cartera a menudo almacenan estimaciones no vinculantes allí para ayudar en la planificación de Sprint y otras actividades de previsión. Del mismo modo, solo el Equipo de desarrollo puede asignar estimaciones de nivel de esfuerzo a los elementos del Backlog o incorporar trabajo a un Sprint Backlog determinado.

El Product Owner nunca asigna trabajo a un Sprint; en cambio, el propietario del producto trabaja con el resto del equipo Scrum para crear un Sprint Goal para cada iteración que proporcione una coherencia central para el trabajo que pueda encajar en el cuadro de tiempo actual. Luego, el equipo de desarrollo extrae el trabajo de la parte superior de la cartera de productos durante la planificación del Sprint, utilizando el objetivo del Sprint como filtro. El propietario del producto y el equipo de desarrollo pueden trabajar juntos para identificar elementos "deberían" y "podrían" relacionados con el objetivo del Sprint, y el propietario del producto puede priorizar dicho trabajo sobre la marcha durante la planificación de eventos cuando el equipo puede tener capacidad adicional.

Recuerde siempre que solo el propietario del producto puede priorizar el Product Backlog, y solo el equipo de desarrollo puede incorporar el trabajo en un Sprint Backlog. Si bien existe una separación formal de responsabilidad para los dos trabajos pendientes, eso no significa que el propietario del producto y el equipo de desarrollo no puedan (o no deban) colaborar. Todo el Equipo Scrum debe colaborar activamente durante todo el ciclo de vida del proyecto, en lugar de arrojarse cosas por encima de la pared entre sí en los límites de Sprint.

MoSCoW no suele ser una buena manera de priorizar un trabajo pendiente. En primer lugar porque no es lo suficientemente fino. Tener solo cuatro categorías fijas se vuelve insuficiente tan pronto como las historias en cualquier categoría superan la capacidad de un sprint. En segundo lugar, la categorización "absoluta" como MoSCoW corre el riesgo de dar a las partes interesadas y los equipos una mentalidad equivocada. Puede provocar una discusión irrelevante sobre lo que "debe" o "debería" ser el caso en lugar de centrarse en lo que realmente importa, que es la prioridad relativa . Me gusta asignar prioridades en una escala del 1 al 1000.