¿Cómo lidiar con la planificación de sprint corriendo demasiado tiempo?

14

Tomé más de 5 horas en la planificación del sprint durante un sprint de una semana. Eso parece demasiado.

Discutimos las cosas en detalle en la planificación del sprint, ya que la mayoría de los miembros del equipo no son senior. Si no lo hacemos, se producirán errores durante la implementación y el rediseño durante el sprint.

¿Cómo nos enfrentamos a esto?

¿Cuántos detalles debería discutir durante la planificación para ajustarlo a solo 2 horas de duración por sprint semanal?

b.ben
fuente
2
¿Qué estás haciendo exactamente en Sprint Planning? ¿Está desglosando historias, refinando requisitos, haciendo diseño, estimando?
Liath
1
Gracias, olvidé decirte. Pasamos la mayor parte del tiempo haciendo diseño.
b.ben
1
¿Estás preparando el trabajo atrasado en una reunión separada? Por lo general, el tiempo de espera de la acumulación de pedidos pendientes es de 1 hora por sprint y la planificación del sprint es de 1 hora por sprint. Eso ha estado funcionando bien para nuestros sprints de 2 semanas.
Berin Loritsch
44
@ b.ben pero "diseño" no es parte de la planificación del sprint.
Thomas Junk
2
er espera, ¿por qué estás hablando de implementación durante la planificación de sprint? La planificación de Sprint es sobre qué no cómo .
candied_orange

Respuestas:

20

Tienes razón: 5 horas en Sprint Planning durante 1 semana Sprint parece mucho tiempo. La Guía de Scrum cronometra la planificación de Sprint a 8 horas durante 1 mes de Sprints y dice que "para Sprints más cortos, el evento suele ser más corto". Si considera la proporción, un buen objetivo puede ser 2 horas de planificación de Sprint para un Sprint de 1 semana, pero no hay un horario fijo.

Entonces, ¿cómo puedes abordar una larga planificación de Sprint?

Como Scrum Master, tomaría los siguientes pasos:

Primero, trabajaría con el Propietario del producto para asegurarme de que el Backlog del producto esté ordenado correctamente. Es esencial para el Refinamiento de Backlog efectivo y la Planificación de Sprint asegurarse de que el trabajo más importante y sus dependencias estén en la parte superior del Backlog del Producto para que el Equipo Scrum pueda enfocar sus energías en definir, refinar y preparar el trabajo correcto.

En segundo lugar, me aseguraría de que el equipo esté dedicando suficiente tiempo al refinamiento de la acumulación. La Guía Scrum indica que las actividades de refinamiento generalmente no requieren más del 10% de la capacidad de un Equipo de Desarrollo. Como ejemplo, un equipo de desarrollo de 4 personas que trabaje una semana estándar de 40 horas debería planear unas 16 horas de refinamiento de la cartera. Esto puede hacerse individualmente, en pequeños grupos o en equipo. Descubrí que tener una sesión planificada de Refinamiento de Backlog para el equipo y luego salir para hacer cualquier investigación o investigación o planificación tiende a funcionar mejor.

En tercer lugar, asegúrese de que el equipo se dé cuenta de que no necesitan obtener todos los detalles en Sprint Planning. El objetivo de Sprint Planning es producir un plan para completar los objetivos de Sprint. No intentes hacer un gran diseño por adelantado en una sesión de Sprint Planning. Comprenda cómo encaja el trabajo, las dependencias y los objetivos diferentes y utilice el tiempo fuera de las sesiones de Sprint Planning con las personas adecuadas para hacer el diseño, la implementación y las pruebas necesarias para entregar el trabajo.

Es posible que se salgan más pasos de estos, pero este sería un buen punto de partida.

Thomas Owens
fuente
3
Básicamente, el equipo seguirá pasando la misma cantidad de horas en las reuniones. Simplemente los llamamos reuniones diferentes. :) Se necesita lo necesario para desglosar las cosas lo suficiente como para que el equipo se sienta cómodo estimando el trabajo y sea independiente cuando llegue el momento de hacer el trabajo.
Greg Burghardt
55
@GregBurghardt: OP escribe que pasan la mayor parte del tiempo haciendo diseño. Entonces, todo el equipo trabaja en el diseño de cada historia. Si divide eso para que solo una parte del equipo trabaje en cada historia respectiva, reducirá el tiempo total dedicado a las reuniones.
Michael Borgwardt
Re: "asegúrese de que el equipo se dé cuenta de que no necesitan tener todos los detalles correctos en la planificación de Sprint": Y, lo que es más importante, asegúrese de que sea realmente cierto que no necesitan tener todos los detalles correctos en la panorámica de sprint .
ruakh
@GregBurghardt Quizás. Pero hay una diferencia entre todo el equipo que está en una habitación durante 5 horas y diferentes combinaciones de personas que están fuera haciendo trabajo de diseño durante 3 horas después de una sesión de planificación de 2 horas.
Thomas Owens
5

Te escucho. ¡Eso es demasiado tiempo para gastar! Con suerte, su equipo está discutiendo esto en sus retrospectivas. Intentamos varios experimentos con resultados mixtos:

  1. Todos hacen un diseño de alto nivel en un boleto único y lo pasan a la izquierda o derecha alrededor de la mesa para su revisión, seguido de una revisión grupal del plan para cada boleto. No a todos les gustó esto, pero obligó a nuestros juniors a intentarlo. Algunas personas en los equipos están muy contentas simplemente dejando que otros piensen y simplemente siguen las instrucciones. Entonces, en el lado positivo, nuestro experimento obligó a todos a enfrentar sus brechas de conocimiento, lo que supuso un desafío de crecimiento para los jóvenes. En el lado negativo, no a todos les gusta que los pongan en el lugar y no necesariamente reduce el tiempo de la reunión. ¡Próximo!

  2. Se intentaron diseños emparejados. Grupos de dos o tres dividirían un ticket en tareas. Todo el equipo revisaría los planes resultantes. Fue mucho más rápido, pero algunos mini-pods tenían el mismo problema de una persona que viajaba mientras que el otro hacía el trabajo en el diseño.

  3. Omita el desglose de la tarea. Decidimos que los puntos de nuestra historia se promediaron, por lo que solo estábamos perdiendo el tiempo tratando de involucrar a todo el equipo en todo. Como resultado, tuvimos reuniones de planificación mucho más cortas, pero el trabajo de diseño fue algo que nuestras parejas tuvieron que hacer por sí mismas cuando comenzaron un boleto. Si los juniors están trabajando en un boleto, esperen que necesiten ayuda para superar este paso. Si intentas esto, aceptaste menos historias en el sprint hasta que te sientas cómodo. Además, asegúrese de que sea "seguro" para sus compañeros de equipo pedir ayuda cuando no saben algo.

Al final, se reduce a la madurez del equipo. Las personas necesitan comprender las habilidades y preferencias de los demás y tener confianza en que los compañeros de equipo pedirán información cuando la necesiten. Arregle los primeros, si no los tiene. Entonces, resolver el problema de las reuniones ineficientes se vuelve más fácil.

Jason Zinschlag
fuente
44
La opción n. ° 3 genera equipos que dependen de una sola persona o un pequeño grupo de personas. Si esa persona o personas no están cerca, la velocidad del equipo desciende por el inodoro. Solía ​​hacer eso con nuestro equipo, y cada vez que esa persona se iba de vacaciones se producía un caos. No se hizo nada. Luego, el líder del equipo pasó 3 semanas tratando de calmar la gestión del proyecto. Si está trabajando en un equipo con juniors o no expertos, definitivamente no recomendaría el # 3. Si tiene todos los expertos (y en realidad son expertos) # 3 puede ahorrarle tiempo.
Greg Burghardt
Si esa persona solo está haciendo la tarea de diseño para todos, claro, estoy de acuerdo. Pero, ¿qué pasaría si esa persona estuviera ayudando a las personas a mejorar en hacerlo ellos mismos?
Jason Zinschlag
2
Según mi experiencia, no mejoran con alguien que los guía a través de las cosas. Se convierte en personas experimentadas que lo hacen por los menos experimentados, porque los menos experimentados tardaron más en llegar. Tuvimos mejor suerte sentando a todos en la sala y haciendo tareas de desarrollo. Incluso pasando por el código, pero no durante la planificación del sprint. Lo llamamos "escribir tareas de desarrollo" porque eso es lo que nuestro equipo necesitaba. Luego comenzaron a ser independientes, y comenzaron a ser mejores y más rápidos al escribir tareas de desarrollo.
Greg Burghardt
Me alegra que tu equipo haya encontrado el camino. ¿Crees que tus experimentados compañeros de equipo estaban tomando el camino fácil? Enseñar a la gente es un dolor de cabeza, lo sé. Pero paga grandes dividendos. La mayoría de las personas no tienen paciencia para ello, y veo exactamente lo que está describiendo: las personas con experiencia pueden perder fácilmente la paciencia con el proceso y "hacerlo por sí mismos". Además, los jóvenes deben ser buenos aprendices.
Jason Zinschlag
@GregBurghardt Creo que hemos hecho algo como "escribir tareas de desarrollo" durante la planificación del sprint. ¿Y no estoy seguro si está bien?
b.ben
3

Me gusta la respuesta que recibió de @ Thomas-Owens pero también agregaré un elemento más. ¿Has considerado hacer programación de pares como parte de tu implementación ágil?

La programación en pareja ayudaría a (1) enseñar a algunos de sus programadores junior cómo escribir un mejor código y (2) en la programación en pareja, no siempre tiene que tener todas las características de diseño establecidas para usted en la planificación del sprint. Con el par trabajando juntos, algunas de esas decisiones de diseño se pueden tomar "espontáneamente" con los beneficios adicionales de programación del par.

Si puede ayudar a sus programadores junior a aprender más rápido y sabe que los elementos de diseño que no abordó en Sprint Planning serán decididos por dos personas, no hay razón para que no pueda reducir el tiempo que dedica a Planificación futura de Sprint

Codificador desconocido
fuente
Sí, eso es lo que quería. Pero nuestro equipo no tiene suficiente personal para hacer eso. Se me ocurre una idea que permitirá a todos los miembros del equipo escribir las abstracciones y las interfaces propias, antes de comenzar a implementar, hagamos una reunión para acordar entre todos los desarrolladores. ¿Qué piensas?
b.ben
1
@ b.ben Pero tu equipo nunca tendrá suficientes adultos mayores hasta que hagas esto. Eso es parte del poder de la programación de pares. Debes comprometerte con esto.
Codificador desconocido
1

No soy aficionado al scrum y solo tengo aproximadamente un año de experiencia práctica. Entonces, lo siguiente debe leerse con un grano de sal.

Veo varias banderas rojas en lo que escribes:

5 horas de planificación de sprint

Esto es demasiado tiempo para un sprint de una semana.

El objetivo de la planificación del sprint es AFIRMAR a

  • permitir al equipo saber cuáles son las prioridades actuales y
  • para desarrollar un plan de batalla para el próximo sprint.

Para hacer esto de manera efectiva, cada lado tiene que entender el Product Backlog items.

Para entender el trabajo Product Backlog itemsatrasado tiene que estar en buena forma.

En la fase de planificación concreta, Product Backlog itemsse transforman en Sprint Backlog items.

Una posible causa es que estos elementos no se aclaran / refinan lo suficiente.

Otra posible causa es que los elementos son demasiado complejos y dejan espacio para demasiada interpretación.

Discutir muy detallado en la planificación de sprint

Como se dijo anteriormente, la fase de discusión será más corta, cuando los ítems sean más concretos.

Por otro lado: la planificación de Sprint espera un comportamiento profesional de cada participante. Esto incluye evitar las discusiones sobre bikeshedding .

Quizás las cosas estén claras, pero alguien comienza una discusión sobre el cambio de bicicletas .

Más: Evite discusiones sobre detalles de implementación . Aunque cada idea termina en código en algún momento, no es el punto de discusión de la planificación del sprint, si una simple matriz hará el truco, o será mejor usar una lista vinculada.

Como la mayoría de los miembros del equipo no son senior

En scrum no hay distinción entre senior y junior . Ambos son solo desarrolladores. Y este es un buen punto de partida, que le ayuda a mantener su discusión centrada en una solución viable respaldada por los mejores argumentos y no por el cheque de pago.

Errores de implementación y rediseño durante el sprint

Parece haber un problema fundamental en la recopilación de requisitos, seguido de una acumulación de productos muy vaga.

Como dije anteriormente: siempre que Product Backlogesté en buena forma, debería ser difícil perder el punto.

No puedo imaginar una situación como:

»¡Como usuario quiero ver un puñado de clientes!«

"Oh, ¿no te refieres a cada uno de nuestros 2 millones de clientes?"

OTOH: ¿Qué significa en este contexto rediseño ? Si un desarrollador elige un algoritmo de rendimiento lento , entonces queda claro el siguiente objetivo: elegir uno de mejor rendimiento. Pero eso no es un "rediseño", es una optimización.


A sus preguntas principales:

Como lidiar con esto?

Es trivial mencionarlo, pero lo hago de todos modos: no olvides que estás tratando con humanos .

Es muy difícil tener un grupo de mentes diferentes, que puedan compartir conceptos comunes (como en Rashomon ). Con el fin de hacer frente eficazmente a esto, el uso tanto de redundancia en la comunicación como sea posible: por ejemplo, explicar el contexto del tema extenso, incluso si todo el mundo "debe saber" qué hacer. Haga preguntas, si todos entienden cuál es el tema de un artículo determinado.

Si estás jugando al poker de planificación, un buen indicador, si la comprensión es lo suficientemente buena, es que las tareas tienen una calificación baja. Bajo significa baja complejidad significa fácil de entender y difícil de perder.

Un efecto secundario de la iteración es que los números para ciertas tareas aumentarán (porque el equipo comprende sus capacidades y las complejidades ocultas). Entonces existe la posibilidad de dividir el elemento en varios elementos menos complejos con menor complejidad.

¿Cuántos detalles debería discutir durante la planificación para encajar 2 horas de duración por sprint semanal?

Respuesta salomónica: lo menos posible y todo lo necesario, pero no más.

tl; dr

  • Elija un idioma fácil (si es útil, use inglés simple o ELI5) para evitar malentendidos

  • Mejora la recopilación de requisitos

  • Mejora la acumulación

  • Aumentar la confianza de los miembros del equipo en sus capacidades individuales, así como en sus capacidades como equipo.

  • Evitar bicicletas

  • Mejora la disciplina personal

  • Tal vez use cajas de tiempo fijas para cada elemento para discutir

  • Fortalecer la posición de scrum mastermoderar con eficacia.

Thomas Junk
fuente
-2

Hemos logrado reducir mucho el tiempo de planificación de reuniones al preparar un total de tres horas en sprints de 2 semanas. Dividimos la preparación en cuatro sesiones. Hacemos 30 minutos de aseo los lunes y 1 hora de aseo los miércoles todas las semanas. Nuestros sprints comienzan el lunes y terminan el viernes. Como resultado, tenemos buena información de las reuniones de preparación que contribuye como aporte a la planificación que lo hace más corto. Nuestro mejor récord fue una reunión de planificación de 30 minutos en uno de nuestros sprints. La mayoría de las veces no lleva más de una hora a una hora y 30 minutos. De todos modos, todavía es el momento, pero la planificación se realizó muy temprano.

Zain2018
fuente