Scrum establece que el equipo debe comprometerse a entregar las historias en la acumulación de sprint. Se da a entender que una vez que han alcanzado este límite, no se agregan más elementos a la acumulación de sprint.
¿Debe priorizarse abiertamente la acumulación de sprints utilizando el método MoSCoW ? De modo que las expectativas del propietario del producto para el X% de las tareas pendientes de primavera fueron las siguientes:
Por lo que puedo ver, este enfoque se beneficia de:
Sin embargo, este enfoque complica el concepto de que los equipos se comprometan a entregar todo el backlog del sprint.
¿Alguien tiene alguna opinión sobre las ventajas y desventajas de este enfoque para la planificación de sprints? ¿O experiencia implementando algo similar?
No, no hagas eso.
Solo las tareas en la cartera de productos podrían priorizarse a través del método MoSCoW. Si uno hiciera lo que sugiere, tratando de obtener una distribución de prioridades en el Sprint backlog, entonces el Equipo ignorará esas prioridades del proyecto.
Considere la situación en la que hay 6000 imprescindibles, 2000 que debería tener, 1500 que podría tener y 500 que no tendrá en su cartera de proyectos. Luego comienza un sprint, con una velocidad real de poder asumir 20 historias (en este escenario hipotético, todas las historias tienen costos de puntos de historia idénticos). Si usara el método MoSCoW para la acumulación de sprint, entonces durante ese sprint terminaría logrando 12 cosas que debe tener, 4 que debería tener, 3 que podría tener y 1 que no tendrá.
Comparando eso con la alternativa de tomar simplemente 20 historias imprescindibles en el sprint, creo que se vuelve obvio qué enfoque es mejor. Suponiendo una velocidad constante, el método MoSCoW-sprint requerirá 500 sprints para completar todos los elementos imprescindibles, mientras que confiar solo en las prioridades del backlog los completaría en 300 sprints (nuevamente, suponiendo esta situación hipotética en la que cada historia requiere el mismo esfuerzo y nada bloquea nada).
Si un equipo de desarrollo se queda sin trabajo durante el sprint, se debe informar al propietario del producto y se debe concluir el sprint antes o se debe agregar más trabajo al sprint. Idealmente, esto no debería ser una ocurrencia muy común. Si un equipo de desarrollo subestima constantemente el trabajo de sus sprints, entonces hay problemas con su proceso de estimación.
Las características/capacidades/entregables/tareas deberían haber sido priorizadas (en la cartera de productos) utilizando MoSCoW durante la recopilación de requisitos antes de comenzar su primer sprint, y según sea necesario durante las reuniones posteriores de refinamiento de la cartera de productos. Durante tales reuniones de refinamiento, es posible que desee revisar esta priorización, pero eso es más bien hacer la pregunta "¿Sigue siendo obligatorio tener el artículo X?" en lugar de tener un porcentaje arbitrario de elementos imprescindibles, imprescindibles, etc.
Lo que debería ver es una cantidad decreciente de historias imprescindibles tanto en su producto como en la acumulación de sprint a medida que avanza en el proyecto. Una vez que llegue al punto en que no le queden elementos imprescindibles en la cola, debe preguntarle al propietario de la empresa si considera que el proyecto está completo al final de cada sprint.
Estoy en una organización que es Scrum-ish, como tantos otros lugares que pasan de hacer estos Waterfall/Traditional y terminan queriendo implementar Agile.
Hacemos una priorización similar para todas las sesiones de planificación de iteraciones, tenemos iteraciones de 15 días y llamamos Need to Have/Nice to Haves en función de las horas comprometidas, lo cual es absolutamente infernal en cuanto a agotamiento y velocidad, ya que tiene historias de usuario/tareas/defectos. constantemente siendo trasladado al lanzamiento de una próxima iteración o retrocediendo a la acumulación para hacer espacio para algo con una mayor necesidad de "negocio".
Así que no haga eso, debería estar haciéndolo cuando esté terminando los requisitos y colocándolo en la cartera de pedidos durante sus reuniones de planificación de Domain Walk/Sprint
Eso es demasiado fino. Los criterios de aceptación deben depender únicamente de los imprescindibles.
Podría estar bien tener también objetivos de "extensión", dependiendo de cómo esté definiendo el objetivo del sprint y seleccionando elementos de la cartera de productos.
Por ejemplo: si el objetivo del sprint es "implementar la funcionalidad X", entonces las historias y el AC están estrictamente limitados al mínimo necesario para implementar la funcionalidad X. Sin embargo, si hay pequeñas tareas relacionadas en la cartera de productos que (según el PO) haría que X fuera más agradable, o implementaría una funcionalidad Y estrechamente relacionada que agregaría valor a X, entonces creo que está bien identificarlos en el momento de la planificación del sprint, tenerlos en cuenta mientras trabaja y llevarlos al sprint si y cuando un ) ha completado todo el trabajo de sprint planificado b) le queda suficiente tiempo para estar seguro de que puede completar la tarea de extensión.
Esto podría ser más un enfoque de prohibición de scrum, supongo.
Dicho esto, alterará tus cálculos de velocidad, así que si eso es importante para ti, no lo hagas. (Incluso si tiene en cuenta los puntos de historia agregados cuando los agrega, existe una diferencia metodológica entre "intentamos X puntos en Y días y nuestra velocidad fue X/Y" y "intentamos X puntos en Y días y terminamos temprano, así que tomamos otros puntos Z porque estábamos seguros de que podíamos hacerlo, woohoo".)
Terminar un sprint temprano también le permite al equipo usar ese tiempo para ponerse al día con la deuda tecnológica y hacer otro trabajo que no sea de sprint, lo cual tiene su propio valor.
alan larimer
Sarov
alan larimer