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?

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.

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.

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

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.

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.