¿Cuánto debe durar una reunión de planificación de sprint?

En su experiencia, ¿cuánto debería durar una reunión de planificación de Sprint (Scrum)? ¿8 horas? ¿O debería ser más corto (sucinto) y deberían planearse más discusiones como parte del sprint? Nuestros Sprints duran 10 días.

De acuerdo con la Guía Scrum :

La reunión de planificación de Sprint tiene un límite de tiempo de ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento es proporcionalmente más corto. Por ejemplo, los Sprints de dos semanas tienen reuniones de planificación de Sprint de cuatro horas.

Eso generalmente funciona para mí.

Mientras tenga que durar, ni menos ni más. Cualquier otra cosa no es ágil.

Si tiene un equipo de 2 a 3 desarrolladores y está haciendo sprints de 1 semana, cualquier cosa de más de una hora probablemente sea contraproducente.

Si tienes un equipo de 15 personas y 2 semanas de sprints que estás viendo todo el día, nada menos no es lo suficientemente detallado.

Se necesita experiencia para hacerlo bien, y para eso están las retrospectivas, el equipo decide qué es demasiado largo o demasiado corto.

No te preocupes por perfeccionarlo o apegarte a lo que dice un libro, prueba algo y refínalo.

SCRUM se trata de refinar el proceso en iteraciones tanto como de refinar su código en iteraciones.

No moldee su negocio en torno al proceso. El proceso respalda su negocio. En el momento en que realiza el proceso por sí mismo, es hora de que el proceso obtenga el hacha. Para ese fin, no hay una forma "correcta". Las reuniones solo deben durar mientras se logra algo en ellas. Si te toma 30 minutos o 4 horas, siempre que funcione, entonces ve con él. Ignora lo que te dice un libro / blog / entrenador y haz lo que sea correcto para ti.

Tómate el tiempo que necesites para seleccionar lo suficiente como para que tu equipo piense que pueden lograrlo razonablemente en el sprint. Pero debería pasar tiempo durante el sprint (anterior) refinando el trabajo atrasado: estimando y refinando historias.

Del Scrum Primer ( PDF ):

Refinamiento de la cartera de productos

Una de las pautas menos conocidas, pero valiosas, en Scrum es que el Equipo debe dedicar cinco o diez por ciento de cada Sprint a refinar (o "arreglar") la Lista de Producto. Esto incluye análisis de requisitos detallados, división de artículos grandes en artículos más pequeños, estimación de artículos nuevos y reestimación de artículos existentes. Scrum no dice nada sobre cómo se hace este trabajo, pero una técnica utilizada con frecuencia es un taller enfocado cerca del final del Sprint, para que el Equipo y el Propietario del producto puedan dedicarse a este trabajo sin interrupción. Para un Sprint de dos semanas, el cinco por ciento de la duración implica que en cada Sprint hay un taller de Refinamiento de Producto atrasado de medio día. Esta actividad de refinamiento no es para elementos seleccionados para el Sprint actual; es para artículos para el futuro, muy probablemente en los próximos uno o dos Sprints. Con esta práctica, la planificación de Sprint se vuelve relativamente simple porque el propietario del producto y el equipo Scrum comienzan la planificación con un conjunto de elementos claros, bien analizados y cuidadosamente estimados. Una señal de que este taller de refinamiento no se está haciendo (o no se está haciendo bien) es que la planificación de Sprint implica preguntas significativas, descubrimiento o confusión y se siente incompleto; El trabajo de planificación a menudo se extiende al Sprint, lo que generalmente no es deseable.

Hacer esto significa que puede concentrarse en la planificación durante la planificación, y no toma todo el día y el equipo comienza a perder el enfoque y aburrirse.

En Scrum, cuando se trabaja en sprints de 2 semanas, la planificación del sprint se ajusta a 4 horas, lo que lo convierte en un evento de medio día. Una razón para la cantidad de tiempo relativamente grande es que el equipo de desarrollo debe ser capaz de aceptar con confianza que todos los elementos que se encuentran en el backlog de Sprint pueden ser entregados, lo que significa que necesitan conocer los detalles. No es raro que, como parte de la planificación del sprint, los equipos se separen del espacio de la reunión por períodos de tiempo para investigar más a fondo y asegurarse de que estén "Listos" para entrar en el backlog del sprint. (Puede ayudar pensar en la planificación del sprint como un evento, en lugar de una reunión).

Use su "Definición de Listo" y el período de tiempo que el evento de planificación del sprint le permite asegurarse de que todos los elementos de la cartera de pedidos que ingresan al sprint sean factibles y estén listos . es decir, se pueden hacer (completamente, según la "Definición de hecho") dentro del sprint, y hay suficiente información para que el equipo pueda hacerlo en este momento.
Tenga en cuenta, por supuesto, que probablemente no quiera hacer esto para TODOS los elementos durante la planificación del sprint, ya que puede llevar mucho tiempo. Intente tener una preparación regular de la cartera de pedidos (fuera de la planificación de sprint) donde puede desglosar los elementos de la cartera de pedidos, y estimar los elementos que aún no se estiman utilizando el póker de planificación, por ejemplo. (He descubierto que esta puede ser una actividad efectiva para una cena de trabajo con el equipo de desarrollo, ¡si tiene el lujo de la disponibilidad de su equipo a la hora de la cena!)

Sin embargo, el propietario del producto a menudo puede agregar elementos de alta prioridad a la cartera de pedidos del producto justo antes de la planificación del sprint, y aunque la preparación de la cartera de pedidos de rutina puede, y normalmente debe hacerse, antes del evento de planificación del sprint, siempre habrá nuevos elementos como este donde el equipo necesita pasar tiempo resolviendo los detalles y estimando la complejidad durante el evento de planificación del sprint, de ahí que pueda extenderse a 4 horas por sprints de 10 días / 2 semanas.

Si necesita tomar discusiones más largas de este evento, entonces puede tener un elemento de reserva en el backlog de sprint para "tener tal y tal discusión para establecer x", pero debe evitar incluir elementos de sprint para hacer lo que sea que vaya a hacer determinar las necesidades realizadas durante esa discusión, ya que esos no son elementos "atrasados" del trabajo atrasado para ir al sprint.

Como la gente ha dicho, hay razones por las que es posible que desee cambiar la forma en que ejecuta Scrum si el proceso no funciona de manera efectiva para usted. Sin embargo, Scrum es un marco muy bien pensado y probado para comenzar, así que me aseguraré de que su razonamiento esté justificado antes de cambiar el proceso.

En la reunión de planificación de Sprint, el equipo debe determinar dos conjuntos de cosas:

A) Lo que desarrollará el equipo durante este Sprint

B) Cómo se desarrollará

Esta reunión debe tener un calendario de hasta dos horas por cada semana del Sprint, dividida en partes iguales para cada parte (parte A y Parte B) de la reunión.

Por lo tanto, durante un Sprint de 4 semanas, esta reunión no debe durar más de 8 horas, hasta 4 horas para la parte A y hasta 4 horas para la parte B.

Durante la parte A, el equipo de desarrollo tiene que estimar la velocidad del equipo que consideran que tendrán durante este Sprint. También tienen que estimar las historias de usuario de máxima prioridad y elegir suficientes historias de usuario (ya estimadas) para completar de acuerdo con la velocidad de su propio equipo estimado.

En la parte B, el equipo de desarrollo discutirá cómo desarrollar las historias de usuarios más desafiantes ya seleccionadas para ser desarrolladas. Lo más probable es que el equipo de desarrollo no tenga tiempo suficiente para discutir cómo desarrollar todas las historias de usuario seleccionadas, por lo tanto, el equipo tiene que elegir las historias de usuario más desafiantes.

Durante el Sprint, el equipo de desarrollo tiene tiempo suficiente para completar esta discusión.

De acuerdo con la Guía Scrum :

Eventos Scrum

Los eventos prescritos se usan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son eventos de tiempo, de modo que cada evento tiene una duración máxima. Una vez que comienza un Sprint, su duración es fija y no se puede acortar o alargar. Los eventos restantes pueden finalizar siempre que se logre el propósito del evento, asegurando que se pase una cantidad de tiempo adecuada sin permitir desperdicio en el proceso.