¿Cuánto debe durar una reunión de planificación de sprint?
16
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.
8 horas por cada 10 días de carrera definitivamente me suena demasiado. Las discusiones que no requieren todo el equipo deben llevarse a cabo en sesiones separadas, solo para los miembros involucrados.
Péter Török
1
Entonces planea otras reuniones en lugar de discutir todo en la planificación. Punto anotado.
wleao
Deben surgir debates sobre las próximas ideas y planes para que la mayoría de los miembros del equipo tengan una comprensión básica y compartida sobre ellos. El criterio es este: durante la reunión de planificación, nadie debería sorprenderse por haber escuchado algo por primera vez. Siempre que ocurra tal "sorpresa", ajuste aumentando la cantidad de comunicación que ocurre antes de la próxima reunión de planificación. (Las excepciones a esto son anuncios verdaderamente innovadores provenientes de los propietarios del proyecto)
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.
Probablemente sea un buen punto de partida, pero también debe tenerse en cuenta que debe adaptar el proceso a su proyecto, equipo y organización para que funcione para usted. El hecho de que otras personas hayan tenido suerte con él no significa que funcionará para usted de inmediato.
Thomas Owens
66
Sin embargo, si vas a probar Scrum, probablemente deberías probarlo según las pautas definidas primero. Entonces, si algo no funciona, refínalo. Si cambia las reglas incluso antes de comenzar, no tiene en cuenta la evidencia empírica que hizo que las personas que idearon Scrum recomendaran lo que recomendaban, sin ninguna evidencia empírica que demuestre que eso es lo incorrecto para usted.
Matthew Flynn
@MatthewFlynn buen punto
HA
En mi equipo de 3, usualmente solo teníamos sprints de media hora, y cuando el equipo tenía 7, usualmente solo era una hora para sprints de dos semanas.
Zymus
27
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.
Una hora parece un poco corta para 3 desarrolladores / sprints de 1 semana. Por otra parte, acabo de terminar un proyecto relativamente pequeño donde hicimos una planificación de sprint semanal de 5 minutos. Depende del proyecto y de las tarjetas, porque a veces se necesita más (o menos) discusión durante la planificación del sprint.
configurador
2
Una de las ideas clave de Scrum, como un marco ágil, es que usted realiza <i> time-box </i> actividades, como el sprint, la reunión de planificación de sprint y el stand-up / scrum diario. El punto es mantener las cosas enfocadas. Time-boxing no significa que no pueda tomar menos tiempo del designado. Solo que no debería tomar más, ya que eso tiende a hacer que las personas pierdan el enfoque y también reduce la cantidad de tiempo que el equipo tiene para hacer el trabajo.
Matthew Flynn
7
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.
¿Por qué no comenzar el proceso como está diseñado y adaptarse desde allí? Si decide utilizar prácticas ágiles y no ha moldeado su negocio en esa dirección, ya está en problemas.
JeffO
3
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.
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.
@GottliebNotschnabel: Gracias, eso es nuevo. He cambiado el enlace por uno que no requiere inicio de sesión.
Hugo
2
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.
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.
Respuestas:
De acuerdo con la Guía Scrum :
Eso generalmente funciona para mí.
fuente
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.
fuente
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.
fuente
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 ):
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.
fuente
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.
fuente
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.
fuente
De acuerdo con la Guía Scrum :
fuente