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 un nuevo diseño durante el sprint.
¿Cómo lidiamos con esto?
¿Cuántos detalles debo discutir durante la planificación para ajustarme a un sprint de solo 2 horas por semana?
Tienes razón: 5 horas en Sprint Planning por 1 semana Sprint parece mucho tiempo. El Scrum Guide cronometra Sprint Planning 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 una caja de tiempo fija.
Entonces, ¿cómo puede abordar una larga planificación de Sprint?
Como Scrum Master, seguiría estos pasos:
Primero, trabajaría con el Propietario del producto para asegurarme de que el Product Backlog esté correctamente ordenado. Es esencial para un efectivo Backin Refinement y Sprint Planning para asegurarse de que el trabajo más importante y sus dependencias estén en la parte superior del Product Backlog, de modo que el Equipo Scrum pueda concentrar sus energías en definir, refinar y preparar el trabajo correcto.
En segundo lugar, me aseguraría de que el equipo esté dedicando el tiempo suficiente al refinamiento de backlog. La Guía Scrum indica que las actividades de refinamiento generalmente no ocupan más del 10% de la capacidad de un Equipo de Desarrollo. Como ejemplo, un Equipo de Desarrollo de 4 personas que trabaja una semana estándar de 40 horas debe planificar aproximadamente 16 horas de Refinamiento del Backlog. Esto se puede hacer individualmente, en grupos pequeños o en equipo. Descubrí que tener una sesión planificada de Refinamiento de Backlog para el equipo y luego hacer una investigación, una investigación o una planificación tiende a funcionar mejor.
Tercero, asegúrese de que el equipo se dé cuenta de que no es necesario que tenga todos los detalles correctos en la Planificación de Sprint. El objetivo de Sprint Planning es producir un plan para completar los Objetivos de Sprint. No intente hacer un gran diseño por adelantado en una sesión de Planificación de Sprint. Comprenda cómo se adaptan los diferentes trabajos, las dependencias y los objetivos, y utilice el tiempo fuera de las sesiones de Sprint Planning con las personas adecuadas para realizar el diseño, la implementación y las pruebas necesarias para realizar el trabajo.
Es posible que se caigan más pasos de estos, pero este sería un buen punto de partida.
te escucho ¡Eso es demasiado largo para gastar! Con suerte, su equipo está discutiendo esto en sus retrospectivas. Probamos varios experimentos con resultados mixtos:
Todos hacen un diseño de alto nivel en un solo boleto y lo pasan a la izquierda o a la 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 jóvenes a intentarlo. Algunas personas en los equipos están muy felices de dejar que otros piensen y 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 juniors. En el lado negativo, no a todos les gusta que los pongan en el lugar y no necesariamente reduce el tiempo en la reunión. Siguiente!
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 mientras que la otra hizo el trabajo en el diseño.
Omita el desglose de tareas. Decidimos que nuestra historia promediaba los puntos, por lo que 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 nuestros pares tuvieron que hacer por sí mismos cuando comenzaron un boleto. Si los juniors están trabajando con un boleto, espere que necesiten ayuda para superar este paso. Si lo intentas, acepta menos historias en el sprint hasta que te sientas cómodo con él. Además, asegúrese de que sea "seguro" que los compañeros de su equipo pidan ayuda cuando no sepan algo.
Al final, todo se reduce a la madurez del equipo. Las personas deben comprender las habilidades y preferencias de cada uno y tener confianza en que los compañeros de equipo pedirán comentarios cuando lo necesiten. Arregla esos primero, si no los tienes. Luego, resolver el problema de 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 realizar programación en pares como parte de tu implementación Agile?
La programación de pares ayudaría con (1) enseñar a algunos de sus programadores junior cómo escribir un mejor código y (2) en la programación de pares, no siempre tiene que tener todas las características de diseño diseñadas 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 la 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 ninguna razón por la que no pueda reducir el tiempo Usted gasta en la planificación de Sprint en el futuro
No soy un aficionado al scrum y solo tengo aproximadamente un año de experiencia práctica. Por lo tanto, lo siguiente debe leerse con un grano de sal.
Veo varias banderas rojas en lo que escribes:
Esto es demasiado largo para un sprint de una semana.
El objetivo de la planificación del sprint es AFAIR a
Para hacer esto de manera efectiva, cada lado debe comprender el Product Backlog items .
Para comprender el Product Backlog items , el trabajo acumulado debe estar en buena forma.
En la fase de planificación concreta, Product Backlog items se transforma en Sprint Backlog items .
Una posible causa es que estos elementos no estén lo suficientemente claros / refinados.
Otra causa posible es que los elementos son demasiado complejos y dejan espacio para demasiada interpretación.
Como se dijo anteriormente, la fase de discusión será más corta, cuando los elementos sean más concretos.
Por otro lado: la planificación de Sprint espera un comportamiento profesional de cada participante. Esto incluye evitar discusiones bikeshedding .
Quizás las cosas estén claras, pero alguien comienza una discusión de bikeshedding .
Más: evite las discusiones sobre detalles de la implementación . Aunque todas las ideas terminan en código en algún momento, no es el punto de la discusión del planeamiento del sprint, si una matriz simple hará el truco o será mejor usar una lista enlazada.
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.
Parece que hay un problema fundamental en la recopilación de requisitos, seguido de una cartera de productos muy vaga.
Como dije anteriormente: siempre que el Product Backlog esté en buena forma, debería ser difícil perder el punto.
No puedo imaginar una situación como:
»¡Como usuario, quiero ver a un puñado de clientes!«
»¿No quiso decir cada de nuestros 2 millones de clientes?«
OTOH: ¿Qué significa en este contexto rediseñar ? Si un desarrollador elige un algoritmo de rendimiento lento , queda claro el siguiente objetivo: elegir uno con mejor rendimiento. Pero eso no es un "rediseño", esta es una optimización.
A tus preguntas principales:
¿Cómo lidiar con esto?
Es trivial mencionar, 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 ). Para hacer frente a esto de manera efectiva, utilice la mayor cantidad de redundancia en su comunicación como sea posible: por ejemplo. explique el contexto del elemento extenso, incluso si todos "deberían saber" qué hacer. Haga preguntas, si todo el mundo entiende cuál es el tema de un artículo determinado.
Si estás jugando a planning poker , un buen indicador, si la comprensión es lo suficientemente buena, es que las tareas se califican como bajas. 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). Luego, existe la posibilidad de dividir el elemento en varios elementos menos complejos con menor complejidad.
¿Cuántos detalles debo discutir durante la planificación para ajustar 2 horas por semana en un sprint?
Respuesta salomónica: lo menos posible y la cantidad necesaria, pero no más.
tl;dr
Elija un lenguaje fácil (si le resulta útil, use inglés simple o ELI5 ) para evitar malentendidos
Mejorar la recopilación de requisitos
Mejorar el trabajo acumulado
Aumente la confianza de los miembros del equipo en sus capacidades individuales, así como sus capacidades como equipo
Evita el ciclismo en bicicleta
Mejorar la disciplina personal
Tal vez use cajas de tiempo fijas para cada artículo para discutir
Refuerce la posición del scrum master para moderar de manera efectiva.
Hemos logrado reducir mucho el tiempo de reunión de planificación al hacer un arreglo de un total de tres horas en 2 semanas de sprints. Dividimos el aseo en cuatro sesiones. Hacemos 30 minutos de aseo en lunes y 1 hora de aseo en miércoles cada semana. Nuestros sprints comienzan el lunes y terminan el viernes. Como resultado, contamos con buena información de reuniones de aseo que contribuye como aportación a la planificación, lo que la hace más breve. Nuestro mejor registro fue una reunión de planificación de 30 min de duración en uno de nuestros sprints. La mayoría de las veces no toma más de una hora a una hora y 30 minutos. De todos modos, aún es hora de completar el cuadro, pero la planificación se realizó muy temprano.