Considere que tenemos 10 elementos de la cartera de productos (PBI) que se han estimado y, si todo sale bien, llegarán a nuestro próximo sprint, después de la planificación del sprint. ¿En qué momento sería apropiado que el equipo pensara en TODOS LOS 10 PBI como una forma de comprender el objetivo final de este esfuerzo de 10 PBI (asumiendo que todos los PBI están asociados con un tema/epopeya común)? Si bien se entiende que cada PBI brindará valor por sí mismo, a menudo es útil para el equipo saber qué sigue, ya que puede ayudar a informar las decisiones técnicas.
Reuniones que he considerado para este trabajo:
Preparación: no parece el momento adecuado porque se trataría demasiado del "CÓMO" cuando deberíamos estar discutiendo el "QUÉ". Planificación: demasiado tarde, ya que los PBI ya se han definido. Siempre supuse que, en ese momento, todos estarían listos para registrarse y realizar las PBI.
¿Cuándo es el momento adecuado para hacer esto? ¿O se trata de un problema de calidad de PBI?
¿Sería esto en la fase de asignación de tareas de Sprint Planning? Creo que es demasiado tarde en el proceso, ya que es posible que la información recopilada durante este esfuerzo ayude a reestructurar las PBI.
El momento (o proceso) adecuado para ello es la preparación de la acumulación. Su objetivo es llevar PBI al estado "Listo". Y no es una reunión independiente, ya que en la Guía Scrum ( http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog ) puede ver que
El refinamiento de la cartera de productos es el acto de agregar detalles, estimaciones y pedidos a los elementos de la cartera de productos.
También se describe claramente en el video de Jeff Sutherland https://www.youtube.com/watch?v=XkhJDbaW0j0 :
Ready-ready [...] no es sólo una buena lista. Tiene ciertas características.
La primera característica que es realmente importante es que el equipo debe poder actuar de inmediato . Necesitan saber qué hacer y necesitan poder hacer algo ahora.
Si no hiciste ninguna investigación y no tienes idea de cómo lo harás, tendrás un problema.
La segunda cosa es que la acumulación de productos en Scrum [...] está diseñada para ser una negociación [...] debe ser algo que se hable entre PO y el equipo, antes de la planificación de Sprint .
Tienes razón sobre la planificación de ser demasiado tarde para esto.
Lo siguiente [...] es ser estimable. El equipo necesita poder estimarlo claramente y dimensionarlo adecuadamente .
A menos que realice una investigación técnica, en la mayoría de los casos, no podrá hacer una estimación clara. Una guía de personas técnicas senior es invaluable en tal situación.
En resumen, debe realizar una investigación adecuada como parte de la preparación del trabajo pendiente para eliminar la incertidumbre y llevar su PBI al estado "Listo".
@Alex Leonov dio una buena respuesta que cubre los conceptos básicos para obtener historias "Listo". Sin embargo, tengo una opinión diferente en respuesta a su pregunta específica:
¿En qué momento sería apropiado que el equipo pensara en TODOS LOS 10 PBI como una forma de comprender el objetivo final de este esfuerzo de 10 PBI (asumiendo que todos los PBI están asociados con un tema/epopeya común)?
En el momento de la planificación del Sprint y durante el Sprint, si se han programado en ese Sprint. De la Guía Scrum :
"El Equipo de Desarrollo modifica el Sprint Backlog a lo largo del Sprint, y el Sprint Backlog emerge durante el Sprint. Este surgimiento ocurre a medida que el Equipo de Desarrollo trabaja en el plan y aprende más sobre el trabajo necesario para lograr el Sprint Goal".
Si, como usted dice, "la información recopilada durante este esfuerzo ayudaría a reestructurar los PBI", continúe y reestructurelos durante el Sprint.
Antes de la Planificación de Sprint, estos PBI son solo historias independientes. Si hace algún trabajo asumiendo que estos 10 PBI se mantendrán juntos, será un esfuerzo desperdiciado. El propietario del producto es libre de mover algunos hacia arriba, otros hacia abajo y eliminar algunos por completo. Además, de la Guía Scrum:
"El propietario del producto es responsable de la cartera de productos, incluido su contenido, disponibilidad y pedidos".
Enfrentamos una preocupación similar con el equipo y terminamos teniendo dos sesiones de preparación de Backlog durante el Sprint de 2 semanas. Nuestro Horario fue el siguiente:
Eso funcionó bastante bien.
¿En qué momento sería apropiado que el equipo pensara en TODOS los 10 PBI como una especie de forma de comprender el objetivo final de este esfuerzo de 10 PBI[?]
Nunca. Está malinterpretando la relación entre el Sprint Goal y el Product Backlog.
Parte de la Planificación de Sprint es la definición de un Objetivo de Sprint global. En general, todas las historias seleccionadas para el Sprint actual deben construirse hacia ese objetivo unificador. De esta manera, un Sprint puede tener éxito incluso si el 100 % de las historias seleccionadas no se completan, siempre y cuando se cumpla el Objetivo del Sprint definido, o las historias se pueden recortar del Sprint actual siempre que no se ponga en peligro el Objetivo del Sprint acordado. . Esto es parte de lo que hace de Scrum un marco tan flexible y poderoso.
Además, el Product Backlog es una serie de elementos a los que el propietario del producto les ha asignado un valor ordinal y el equipo de desarrollo un nivel relativo de esfuerzo (por ejemplo, puntos de la historia). El equipo de desarrollo saca elementos de la parte superior de la cartera de productos de uno en uno, siempre que haya suficiente capacidad dentro del Sprint para completar esa historia dentro de la iteración . El equipo nunca acepta historias en el Sprint simplemente porque están relacionadas con otras historias; todas esas decisiones deben basarse en:
El Equipo Scrum debe trabajar, en todos y cada uno de los Sprints, hacia un Sprint Goal unificado. En ningún momento, el equipo considera las historias en el Product Backlog de esta manera. Sin embargo, durante la planificación del Sprint, el equipo de desarrollo siempre debe tener en cuenta el objetivo del Sprint al planificar y organizar el Sprint Backlog, y el equipo de desarrollo debe considerar todos los elementos aceptados del Sprint Backlog juntos al planificar el Sprint actual.