Nuestras reuniones de planificación de sprints no solo no son divertidas, sino que son francamente espantosas.

Las reuniones son tediosas y aburridas, y duran una eternidad (un día, pero parece mucho más tiempo).
Los desarrolladores se quejan y temen las próximas planificaciones.

Nuestra rutina es bastante estándar (la historia del usuario se inserta en el backlog de Sprint por prioridad >> la historia se desglosa en tareas >> las tareas se estiman en horas >> repetir), y no puedo entender qué estamos haciendo mal.

¿Cómo podemos hacer que las reuniones sean más agradables?

...

Algunos detalles más, en respuesta a las solicitudes de más información:

¿Por qué los elementos de la cartera no se insertan y priorizan antes del inicio del sprint?

Las historias de usuarios tienen prioridad; ¡No tenemos idea de cuánto tiempo tomarán hasta que los dividamos en tareas! De las respuestas (excelentes) aquí, veo que tal vez no deberíamos estimar las tareas en absoluto, solo las historias de los usuarios. La razón por la que estimamos las tareas (y no las historias) es porque hemos estado recibiendo estimaciones de historias terriblemente erróneas, pero supongo que ese es el tema de una pregunta completamente diferente.

¿Por qué se quejan los desarrolladores?

1. Las reuniones son largas.

2. Las reuniones son monótonas. Historia tras historia, tarea tras tarea, luchando (sí, luchando) para estimar cuánto tiempo llevará y lo que implica.

3. La estimación de tareas hace que la estimación de la historia del usuario parezca inútil.

4. Cuanto más larga sea la reunión, menos concentración habrá en la sala. Cuantos menos colegas se centren, más durará la reunión. Se desarrolla una espiral de odio recursiva. Hemos considerado dividir la reunión en dos días para mantener a la gente enfocada, pero los desarrolladores no se enteraron. Un día de planificación ya es bastante malo; ahora tendremos dos ?

Parte de nuestro problema es que entramos en detalles muy pequeños (para obtener estimaciones más precisas). Pero cuando estimamos aproximadamente, ¡vamos muy lejos!

Para resumir la pregunta:

• ¿Qué estamos haciendo mal?

• ¿Qué formas adicionales hay para que la reunión sea más agradable en general?

Hacer la estimación más fácil

Rompe tu planificación de sprint.

¿ Necesita estimar las tareas individuales? He hecho la planificación de sprint de dos maneras:

1. Las historias se estiman en puntos de historia y luego las tareas se estiman en horas
2. Las historias se estiman en puntos de historia y las tareas simplemente caen dentro de eso sin estimación

De los dos, prefiero la segunda opción. Creo que no estimar las tareas da más libertad a los desarrolladores para hacer frente a los cambios. Si una tarea ya no tiene sentido (cuántas veces has descubierto que una tarea no es aplicable o que ya se realizó en un sprint anterior), simplemente la descartas sin penalización, o puede que tengas que cambiar una tarea actual a algo nuevo, posiblemente rompiéndolo. Realmente estás siendo redundante si estimas ambos, ya que la suma de las tareas debe representar los puntos de la historia y viceversa. ¿Qué valor gana realmente con esto además de saber cuánto tiempo llevará las tareas individuales? Si se encuentra con tamaños de tareas que realmente varían lo suficiente como para marcar la diferencia, sugeriría dividir esas tareas en trozos más pequeños y más homogéneos.

Al hacer esto, puede reducir el tiempo que dedica a la planificación de sprints . Las historias se estiman durante la planificación del sprint, y cuando comienzas el sprint puedes dejar todas las tareas que puedas imaginar para hacer esa historia. Obviamente, si hay puntos con los que se encuentra al estimar la historia que sabe que tendrá que tratarse en una tarea, puede agregarla a la información de la historia y ponerla como una tarea.

Estimación en unidades ideales

Los puntos de la historia están destinados a estar en unidades ideales , como horas de trabajo ideales o días de trabajo ideales. Esto significa que, dado el día perfecto todos los días, donde no hubo interrupciones ni reuniones, y todo salió según lo planeado, podría realizar la tarea en X días. Ahora todos saben que esto simplemente no es cierto, pero lo maravilloso de las estadísticas es que no tiene que ser así.

Lo que quiero decir con esto es que después de un tiempo de estimar estos en días ideales, te das cuenta de que tal vez se necesita un 25% extra del tiempo que estimas en promedio para completar una historia. Digamos que había estimado 4 días de trabajo ideales, y en su lugar le tomó 5. Con el tiempo, realiza un seguimiento de esto y luego tiene una idea aproximada de la conversión de días ideales a días reales. Su primer instinto sería intentar compensar esto sobreestimando, y es probable que se equivoque. Lo principal aquí es mantenerse constante. De esa manera, su promedio a largo plazo sigue siendo el mismo. Claro que a veces, estará abajo y a veces habrá terminado, pero cuanto más calcules, mejor estarás. Si encuentras que todavía no puedo obtener una estimación decente, tal vez eso significa que no sabes lo suficiente sobre la historia para estimarla correctamente.

Habla sobre las historias

Cuando calcule, todos deben tener una idea aproximada de lo que deberá hacerse, de principio a fin, de lo que se necesitará para completar esta historia. No necesita conocer cada detalle, pero lo suficiente como para pensar que usted mismo podría emprender la historia. Si no tiene ese nivel de confianza, probablemente no debería estimarlo. Si dice "Bueno, esta historia es demasiado grande para que podamos conocer la mayoría de los detalles", entonces eso es una indicación de que la historia es demasiado grande y debe desglosarse. Las historias, al menos en mi experiencia, han sido lo suficientemente pequeñas como para que una persona, si es necesario, pueda trabajar en ello solo y lograrlo en una o dos semanas.

Esto también ayudará a resolver su segundo punto en la edición, que es demasiada estimación . En lugar de estimar cada tarea para cada historia, simplemente estima la historia como un todo, lo que debería ayudar a eliminar gran parte de la estimación. En cuanto a hacer que las reuniones sean menos monótonas, sugeriría planificar el póker, del cual puede ver más información más arriba.

Hacer que la planificación sea más atractiva

Estimación usando Planning Poker

En cuanto a hacer que la estimación sea más divertida, ¿has intentado planificar el póker ? Es la forma en que siempre he hecho la planificación de todos mis sprints en varios equipos, y es una buena manera de mantener a todos involucrados, ya que cada persona debe al menos elegir ALGO. También hay una gran cantidad de diversión cuando todos en el equipo eligen 3, y alguien pone un 20 y tiene que explicarse, o cuando todos en el equipo ponen un 5 pero el gerente pone un 8 (quién discutirá con ¡el jefe cuando quiera darte más tiempo!).

Para hacer esto, todo lo que necesita son algunas cartas de póker de planificación , que a menudo hacemos en el reverso de las tarjetas de índice, o el uso de cartas normales con valores unidos a las cartas de cara. Nada lujoso, y mantiene a todos enfocados. Solo recuerda que intentar hacer cualquier tarea durante un día entero (incluida la planificación del póker) afecta la productividad. Muchos juegos de tarjetas vienen con una tarjeta de café por una razón; Si alguien se siente agotado, ¡dale un descanso al equipo para recargarlo y retomarlo cuando todos estén frescos!

Como alternativa a las tarjetas físicas , también puede mirar las tarjetas electrónicas . Los beneficios reales aquí son el seguimiento automatizado de los resultados, el seguimiento de las historias de los usuarios para estimar y permitir que todos muestren sus tarjetas a la vez para evitar "hacer trampa" (donde la estimación de una persona está influenciada por la de otros debido a que pueden ver su tarjeta). Obviamente, esto requiere que todos tengan una computadora y la capacidad de concentrarse en la tarea en cuestión, así que úsela a su propio criterio.

1. ¿Por qué los elementos de la cartera no se insertan y priorizan antes del inicio del sprint? Perder el tiempo de los desarrolladores no es divertido. Deje que los líderes de su equipo trabajen con el propietario del producto y el gerente del proyecto unos días antes para priorizar las cosas. Esto también se aplica para planificar quién está en cada equipo de sprint.

2. ¿Por qué lleva un día dividir las cosas en tareas? Si tiene un equipo de tamaño razonable (2-4 desarrolladores, .5-1.5 QA personas por desarrollador, 1-2 misceláneos), entonces debería tener 2-4 historias de usuarios este sprint. Pase 30 minutos más o menos con el propietario del producto aclarando los requisitos, luego 30 minutos más o menos dividiéndolo en tareas de ~ 8 horas. No ingrese las tareas durante la reunión. Simplemente acuerde como equipo cuáles son las tareas suficientes para que las personas sensatas las entiendan, quién es responsable de ellas y cuánto tiempo deben tomar. Acuerde que "cuánto tiempo deben tomar (incluidas las pruebas)" se ajusta cómodamente dentro del sprint.

3. Si no se trata solo de dividir las cosas en tareas, ¿qué más estás haciendo? Claro, las retrospectivas pueden tomar de 30 a 60 minutos, pero serán más cortas a medida que los equipos entren en ritmo.

En resumen, deje de perder el tiempo de las personas y temerán un poco menos las reuniones. Más allá de eso, la diversión y la camaradería en el equipo no es algo que pueda abordar en las reuniones. Vayan a almorzar juntos, bromeen, mezclen a las personas para tener un mejor ajuste de personalidad, tengan concursos de crecimiento de bigotes ... una vez que la moral suba, la gente naturalmente hará que las reuniones de planificación de sprint sean más alegres.

La planificación es un área de scrum donde los equipos tienen mucha flexibilidad. Pruebe algo nuevo cada sprint hasta que encuentre algo que funcione para su equipo.

Algunas ideas exitosas que he probado personalmente o que escuché de otros equipos:

• Realice la creación y priorización de historias de usuario sin todo el equipo. El propietario del producto y / o el scrum master pueden manejar gran parte del trabajo ocupado y simplemente dejar que el equipo lo modifique.
• Haga su cartera de pedidos significativamente más larga que un solo sprint. Puede llevar un tiempo construirlo, pero si su cartera de pedidos es lo suficientemente larga, la planificación de las reuniones se reduce a hacer pequeños ajustes o abordar los desarrollos comerciales recientes.
• Tenga reuniones de estimación separadas de la planificación del sprint. Si la gente piensa que las reuniones son demasiado largas, no hay razón para no dividirlas.
• Específicamente, el plan interrumpe la agenda. Esto es útil si a menudo pierde el tiempo esperando que regresen uno o dos miembros del equipo.
• Interrumpa a la mitad de la reunión y asigne a todos para que resuelvan una o dos historias de usuarios, luego se reúnan para informar y obtener consenso.
• Asegúrese de que su reunión de planificación sea sobre qué hacer, no cómo hacerlo. Los ingenieros caen muy fácilmente en este último. Si es necesario, organice reuniones de diseño separadas donde debata el cómo.
• Separe sus historias en investigación e implementación. Las reuniones de planificación a menudo duran demasiado cuando los miembros del equipo saben muy poco sobre en qué trabajarán y tratan de resolverlo durante la reunión.
  Por ejemplo, supongamos que necesita integrarse con una API con la que su equipo no tiene experiencia. En lugar de intentar crear estimaciones y tareas durante la reunión de planificación sobre algo de lo que no tiene idea, haga una historia de investigación para aprender la API, haga una aplicación sencilla de "hola mundo" y enséñela al equipo. Entonces estará equipado para planificar el trabajo real.
• Mantenga un registro durante sus reuniones de temas específicos. No solo "la planificación es aburrida", sino un nivel de detalle como "pasamos mucho tiempo hablando de requisitos poco claros y nadie parece saber la respuesta correcta". Luego discuta esos problemas específicos en sus retrospectivas y haga una lluvia de ideas para encontrar soluciones específicas. Divide tu problema hasta que las piezas sean fáciles de resolver.

Llevamos a cabo nuestra planificación de sprint y retrospectiva al mismo tiempo, y casi siempre lo hacemos en 90 minutos, pero somos uno de los equipos más rápidos. Hacemos una gran planificación a largo plazo de toda la empresa cada 5 sprints que lleva de 4 a 6 horas. Cada equipo es diferente, por supuesto, pero si pasas un día entero cada sprint, hay mucho margen de mejora.

¡Tus sesiones de planificación son demasiado largas!

Según mi experiencia, una reunión de planificación de sprint no debería tomar más de 2 horas por semana (p. Ej., Un sprint de 2 semanas debería durar medio día como máximo), pero las reuniones exitosas deberían ser más cortas (la mitad).

En su caso particular: ¿por qué estima las tareas? Debe estimar solo historias durante la planificación. Las tareas pueden ser estimadas posteriormente por los propietarios de tareas específicas .

Una forma que funcionó para mí:

• Introducción rápida al sprint por el PO
• Estimación de la capacidad de sprint.
• Las historias se agotan y se planea el póker (con un tiempo de 5/10 minutos por historia) hasta que haya suficientes cosas estimadas para cubrir el sprint
• Compromiso oficial / pronóstico del equipo

Luego, en paralelo / pares / autoorganizados en nuestros escritorios, tareas y estimación de tareas.

En mi trabajo anterior, todo el primer día de cada sprint (los llamamos iteraciones allí) se tomó con:

• Retrospectivo. Comenzamos a hacer esto en la tarde del último día, pero a menudo nos encontramos retrospectivamente sobre el sprint y luego volviendo al trabajo atando los últimos cabos sueltos del trabajo de ese sprint, así que pensamos que sería mejor asegurarnos de que todo el trabajo estaba detrás de nosotros antes de retrospectivamente. También parecía lógico consolidar todos los gastos generales de la reunión del proceso Scrum para que los otros días se pudieran planificar y gastar en términos más ideales. Esto generalmente tomó 2 horas.
• Planificación de Sprint. El retraso se calculó durante una reunión de planificación de hitos (que podría ser un día completo en sí mismo para los desarrolladores y las OP), y las OP habían priorizado antes del comienzo de cada sprint. Descubrimos cuántos días de desarrollador teníamos disponibles (contabilizando vacaciones, vacaciones, etc.), tomamos el trabajo que pensamos que podíamos hacer desde la cima y revisamos rápidamente los requisitos del usuario (previamente examinados por nuestros BA) para Obtenga una idea más completa de lo que implica el trabajo de lo que obtuvimos con la descripción general simple durante el MPM. Esto típicamente tomó otras 2 horas.
• Planificación de tareas. Conociendo las historias y los criterios de aceptación, desglosamos cada historia en tareas del tamaño de un bocado, estimadas en horas ideales (una hora dedicada centrada únicamente en hacer esa tarea "sin" distracciones ni obstáculos). Por la forma en que nuestra escala de puntos terminó siendo calibrada, un 5 fue un sprint de desarrollador, por lo que un 1 podría ser cualquier cosa hasta dos días de desarrollador. Por esa razón, prácticamente todo tuvo que desglosarse para que los miembros del equipo pudieran mostrar el progreso en el tablero de scrum. Este fue otro bloque de 2 horas, con algo de toma y daca entre este y el siguiente elemento.
• Esquema de AAT. Nuestros PO y BA no eran programadores y no codificaban. Las OP se escondieron detrás de un contrato que estipulaba que cumplirían los requisitos en forma de una plantilla de Word y trabajarían con los BA para refinarlos en esa forma. Los BA entendieron el código, pero su tiempo era puramente análisis y pruebas finales (que requerían que el sistema existiera, para que pudieran registrar sus macros en Selenium). Entonces, para verificar que nuestro código cumpliría con los criterios de aceptación cuando se tratara de eso, tuvimos que escribir nuestros propios AAT que modelen las acciones de la prueba de aceptación "en papel". Por lo general, hicimos esto en el mismo marco de NUnit que utilizamos para las pruebas unitarias y de integración (probamos FitNesse y no pudimos abandonarlo lo suficientemente rápido). Este fue el resto de nuestro primer día de cada sprint y continuó en el segundo.

En mi trabajo actual, todavía estamos adoptando el proceso Scrum, no teníamos una planificación de hitos para todo el equipo y mucho de lo que estamos trabajando no tiene criterios de aceptación estrictos. Por lo tanto, nuestra planificación de sprint es tanto una explicación de lo que implica cada historia y lo que llamaremos hecho como un compromiso de aprovechar las X horas ideales de trabajo. Nos salimos con la suya, al menos por ahora, porque somos un equipo interno y cada uno de nosotros trabaja personalmente con los usuarios finales de nuestro software para reunir requisitos y diseñar soluciones. Incluso entonces, la planificación de sprints es algo que dura toda la mañana todos los lunes, y la tarde se dedica a eliminar cualquier obstáculo personal para poder comenzar el desarrollo en serio el martes.

Para responder realmente a la pregunta del OP en lugar de contrastar otros comentarios / respuestas que dicen que no debería llevar tanto tiempo, hay formas de abordar la estimación ágil, la planificación de sprints y las retrospectivas que son un poco más interesantes de lo que podría estar usando.

Abordar específicamente sus inquietudes:

• Las reuniones son largas . Cada reunión, ya sea retrospectiva, planificación de sprint, desglose de tareas, etc., debe tener un propósito definido y un tema de discusión, y debe limitarse tanto como sea posible a un período de tiempo determinado. El trabajo del Scrum Master es mantener estas reuniones en el tema y avanzar para cumplir con los objetivos de tiempo.

• Las reuniones son monótonas . Habrá algo de eso; estás trabajando en trozos pequeños, uno a la vez, por lo que harás lo mismo una y otra vez. Ayudará a mantener enfocado al equipo y a lograr el propósito de la reunión.

  Algo más que escuché es que quizás sus reuniones de planificación de sprint están tratando de lograr demasiado. En mi última compañía, la estimación de la historia se realizó en "reuniones de planificación de hitos", que ocurrían una vez por trimestre y tomaban todo el día. En esas reuniones, todo lo que se había acumulado en la cartera de pedidos que no habíamos estimado se estimó en puntos. Si está haciendo la estimación de la historia en puntos, y luego la estimación de la tarea en horas, no desea hacer ambas cosas al mismo tiempo (tal vez el mismo día).

• Estimar historias en puntos, luego las tareas en horas parecen redundantes : tienen dos propósitos diferentes. El propósito de la estimación de la historia es proporcionar una estimación aproximada de la complejidad, que puede usar para completar su reserva de sprint basada en la velocidad pasada y el ancho de banda esperado. El propósito de la estimación de tareas es dividir las historias en cosas que demoran un día de desarrollador o menos (y por lo tanto pueden asignarse a un solo individuo que se espera que lo haga todo a tiempo), y asegurarse de que no calculó mal la complejidad de cualquier historia ni mordió más de lo que puede masticar en el sprint.

  Si todas sus historias tardan un día o menos, entonces es redundante, pero no todas las escalas de puntos están calibradas por igual; en mi último trabajo, un 5 fue dos semanas de desarrollador (porque al principio teníamos muchas epopeyas para estimar), lo que en una escala lineal resaltaba hasta 2 días de desarrollador. Dado ese tipo de escala, prácticamente todo debería desglosarse en tareas. En mi nueva empresa, un punto está más cerca de la mitad del día del desarrollador, por lo que un 1 o incluso un 2 es definitivamente su propia tarea, y 3-8 es nebuloso con respecto a obligar al equipo a dividirlo en tareas.

• Hay un círculo vicioso que lleva más tiempo haciendo que las personas estén menos concentradas, por lo que lleva más tiempo: marcar el tiempo en su caja de tiempo. Tómese descansos, tal como debería ser cuando codifica. Cada 30 minutos, tome 5 minutos para estirar las piernas, reagruparse, etc. Puede hacerlo diez minutos cada hora, pero no empuje un bloque sólido de tiempo de reunión mucho más que eso. Sus muchachos podrían estar hambrientos, o necesitar más café, o un descanso en el baño, etc. No los nieguen; si haces que se lo traguen, encontrarás sus mentes errantes. Más allá de eso, ayudar a mantener las discusiones cortas, dulces y al punto también ayudará, como se mencionó anteriormente.

La reunión de planificación de Sprint tiene 2 partes:

1. Decide qué hará el equipo
2. Decide cómo lo hará el equipo.

La primera parte es relativamente sencilla: en función de la cantidad de puntos de historia que el equipo siente que puede asumir, el compromiso de completar tantas historias de usuarios en su orden de prioridad. Hecho.

La segunda parte es lo que los desarrolladores deberían disfrutar: la elaboración de la historia y el diseño de la solución. Las tareas se caen de eso. Entonces, haga que el propietario del producto, o cualquier PYME que haya proporcionado, explique una historia elegida. Luego, tenga el desarrollador que quiera asumir, lidere la discusión del diseño. Usa una pizarra blanca. Rebote ideas. Que te diviertas.

Eso es todo. Si las reuniones de diseño no son divertidas, entonces hay algo simplemente mal.

Sí, sé que esta es una vieja pregunta, pero tengo una nueva respuesta. :PAGS

Divide la reunión.

Dividimos nuestra reunión de planificación de Sprint en 3 mini-reuniones separadas

• Preparación del trabajo atrasado
• Selección de historia
• Desglose de tareas

Hacemos cada uno en un día diferente, justo después de nuestro Scrum diario: tan pronto como termina el día, pasamos directamente a la actividad de planificación, y luego estamos libres de reuniones (planificadas regularmente) el resto del día.

Así que sí, estropeamos nuestra planificación: -O

Voy a entrar en más detalles sobre lo que implica cada sesión en un segundo, pero déjenme explicar cómo llegamos a esto.

Nosotros, como usted, tuvimos un problema con las terribles reuniones de planificación de Sprint. Teníamos todos los elementos correctos, pero todo nos llevó una eternidad y fue realmente agotador mental y emocionalmente.

Entonces tuve esta idea después de leer este artículo de Business Insider sobre los 5 minutos diarios de Pivotal sobre dividir nuestras reuniones en sesiones más cortas y hacerlas al comienzo de cada día.

Lo mencioné con el equipo en una retrospectiva. A algunos miembros del equipo les gustó de inmediato, otros estaban un poco aprensivos, pero luego nuestro interno mencionó algún estudio que leyó sobre la técnica de pomodoro y comenzó a hablar sobre eso, y eso realmente ayudó a que la idea ganara terreno.

Entonces decidimos probarlo.
Dividimos nuestra reunión de 2 horas en tres sesiones de 25 minutos. (sí, eso es matemática confusa, pero todos sintieron que nuestras reuniones eran demasiado largas y solo querían hacerlo si ahorramos tiempo).

¡Y funcionó! Lo hemos estado haciendo durante aproximadamente 6 semanas en dos proyectos separados (6 sprints de dos semanas en total) y ha hecho una gran diferencia.
Somos mas productivos. Ahorramos mucho tiempo.
Obtenemos mejores resultados. Y ya no tememos nuestras reuniones de planificación.

Y, sinceramente, nuestro intervalo de tiempo de 25 minutos es bastante flojo: algunas sesiones son muy rápidas, como 5-10 minutos en algunas de nuestras sesiones de preparación, y algunas duran mucho, como cuando terminamos identificando historias nuevas o teniendo que dividir historias. y reestimar durante la negociación. Sin embargo, en general, el promedio es de no más de 1.5 horas durante todo el shebang, y creo que es por eso que funciona tan bien.

A los detalles .....

Preparación del trabajo atrasado

Bastante simple: revisamos las historias de mayor prioridad, hablamos sobre lo que implican y nos aseguramos de que nuestras estimaciones sean buenas.

Volveremos a estimar las historias si es necesario, como decir que calculamos algo hace meses y después de darnos cuenta de lo que realmente tomó una historia similar, podríamos acordar volver a estimar. (utilizamos puntos de historia sin unidades por cierto, y no estimamos tareas ).

Además, si el OP ha agregado alguna historia nueva que él considera de alta prioridad, este es el momento de estimarlas.

Debido a que no hacemos la selección de la Historia hasta el día siguiente, este proceso le da al PO un poco más de tiempo para hacer un juicio final sobre lo que es más importante hacer en la próxima iteración, y esto ha demostrado ser muy útil.

Esta reunión tiende a ser corta con algunas OP y larga con otras. (Personalmente, creo que es un excelente indicador de olor de cómo está su PO)

Selección de historia

Encienda su Chris Voss , es hora de negociar.

En esta reunión, tomamos las historias de mayor prioridad y definimos un DoD para cada uno. Negociamos lo que cada uno implicará, dividiendo y combinando historias según sea necesario, hasta que todos podamos acordar nuestros objetivos de Sprint.

Nos beneficiamos mucho de tener mentes frescas y esa energía de buenos días para esta reunión, y saber que haremos las tareas otro día nos permite pasar el tiempo que necesitamos para negociar bien y comprender nuestros compromisos.

Tareas

Bien, entonces seré el primero en decir que las tareas fueron mi MENOS parte favorita de la planificación en nuestras viejas reuniones de un día.

Simplemente nunca aceleramos con esto. Intentamos guardar tareas hasta el final de la reunión, pero para entonces todos estábamos agotados y fue realmente improductivo. Intentamos definir tareas al mismo tiempo que nuestro Departamento de Defensa durante nuestra negociación, pero nos pareció demasiado molesto y demasiado engorroso: nos agotaríamos antes de seleccionar todas las historias. Además, fue muy difícil seguir cambiando el enfoque / pensamiento entre estimaciones, negociaciones, selección de historias y generación de tareas. Luchamos, y apestaba, e hizo que nuestras reuniones fueran terribles.

Pero ahora, al definir el DoD en un día, y no hacer tareas hasta el siguiente, no nos agotamos, siempre estamos en la mentalidad correcta, y nos da todo un día para marinar sobre la historia y realmente pensar y comprender todas las tareas antes de comenzar.

Esto solo, en mi humilde opinión, es un cambio total del juego.

Poniendolo todo junto.

Entonces, así es como se ve nuestro calendario de ceremonia de Sprint ahora:

• Lunes - Scrum diario -> Revisión de Sprint
• Martes - Scrum diario -> Preparación del trabajo atrasado
• Miércoles - Scrum diario -> Selección de historia
• Jueves - Scrum diario -> Tareas
• Viernes - Scrum diario -> Retrospectiva

Nos ha funcionado muy bien. Si le das una oportunidad, me encantaría saber lo que piensas.

Estamos teniendo un sprint semanal con una reunión de una hora en la que discutimos el sprint anterior, lo que queda por hacer y luego pasamos a la planificación de la próxima semana. Todo dentro de una hora.

Por supuesto, esto se debe a que descubrimos que, en nuestro caso, seguir el scrum demasiado estrictamente solo perdería demasiado tiempo. Esto se debe a que la mayoría de las historias ya se discuten con los miembros de nuestro equipo cuando el solicitante crea la historia del usuario.

Solo digo que si su equipo teme planificar las reuniones, probablemente debería dejar de lado algunas de las "reglas" de scrum.

Esta pregunta ha sido respondida de manera integral, pero solo se necesita una cosa para que funcione y sea divertida.

Dale poder al equipo. - es decir, hacer que funcionen en las cosas que se cree son los más importantes.