Cómo hacer que la planificación de sprints sea divertida

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/204904

Pregunta

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

Las reuniones son tediosas, aburridas y duran una eternidad (un día, pero parece mucho más).
Los promotores se quejan de ello y temen los próximos planes.

Nuestra rutina es bastante estándar (la historia del usuario se inserta en el trabajo pendiente del sprint por prioridad >> la historia se descompone en tareas >> las tareas se estiman en horas >> se repiten), 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 solicitudes de más información:

¿Por qué los elementos del trabajo pendiente no se insertan ni se priorizan antes del inicio del sprint?

De hecho, se priorizan las historias de usuarios;¡No tenemos idea de cuánto tiempo tomarán hasta que los dividamos en tareas!De las (excelentes) respuestas aquí, veo que tal vez no deberíamos estimar tareas en absoluto, solo las historias de usuarios.La razón por la que estimamos tareas (y no historias) es porque hemos estado haciendo estimaciones de historias terriblemente equivocadas, 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 qué implica.

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

  4. Cuanto más larga sea la reunión, menos concentración habrá en la sala.Cuanto menos concentrados estén los colegas, 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 concentrada, pero los desarrolladores no quisieron ni oír hablar de ello.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 hacemos una estimación aproximada, ¡nos equivocamos mucho!

Para resumir la pregunta:

  • ¿Qué estamos haciendo mal?

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

¿Fue útil?

Solución

Facilite la estimación

Divide tu planificación de sprint.

Tú necesidad estimar las tareas individuales?He realizado la planificación de sprints 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 la historia y las tareas simplemente caen dentro de eso sin estimación

De las dos prefiero la segunda opción. Encuentro que no estimar tareas les 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 ninguna penalización, o es posible que tengas que cambiar una tarea actual a algo nuevo, posiblemente rompiéndolo.Realmente estás siendo redundante si estimas ambas, ya que la suma de las tareas debería representar los puntos de la historia y viceversa.¿Qué valor obtiene realmente con esto además de saber cuánto tiempo llevarán las tareas individuales?Si se encuentra con tareas que realmente varían lo suficiente como para marcar la diferencia, le sugeriría dividirlas en partes más pequeñas y homogéneas.

Al hacer esto, puedes Reduzca 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 anotar todas las tareas que se te ocurran y que componen esa historia.Obviamente, si hay puntos con los que te encuentras al estimar la historia que saber Tendrá que ser tratado en una tarea, puede agregarlo a la información de la historia y ponerlo como una tarea.

Estimación en unidades ideales

Los puntos de la historia están destinados a estar en ideal unidades como horas hombre ideales o días laborales ideales.Esto significa que si tuvieras el día perfecto todos los días, sin interrupciones ni reuniones y todo saliera según lo planeado, podrías realizar la tarea en X días.Ahora todo el mundo sabe que esto simplemente no es cierto, pero lo maravilloso de las estadísticas es que no tiene por qué serlo.

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ías estimado 4 días laborales ideales y en cambio te 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 probablemente se equivocaría.Lo principal aquí es manténgase constante. De esa manera, su promedio a largo plazo seguirá siendo el mismo.Claro que a veces será bajo y otras veces será terminado. pero cuanto más estimes, mejor estarás. Si encuentras que tu aún Si no puedes obtener una estimación decente, tal vez eso signifique que no sabes lo suficiente sobre la historia para estimarla correctamente.

hablar de las historias

Cuando estimas, todos deberían tener una idea aproximada de lo que será necesario hacer, de principio a fin, de lo que será necesario para que esta historia esté completa.No es necesario que conozcas todos los detalles, pero sí lo suficiente como para pensar que tú mismo podrías 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 conozcamos 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 fuera necesario, pudiera trabajar en ellas sola y lograrlas en una semana o dos.

Esto también ayudará a resolver el segundo punto de la edición, que es demasiada estimación.En lugar de estimar cada tarea para cada historia, simplemente estima la historia en su conjunto, 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óquer, sobre el cual puedes ver más información arriba.

Haga que la planificación sea más atractiva

Estimar usando Planning Poker

En cuanto a hacer que la estimación sea más divertida, has probado planificación del póquer? Es la forma en que siempre he planificado todos mis sprints en múltiples equipos, y es una buena manera de mantener a todos involucrados, ya que cada persona tiene que al menos elegir ALGO.También hay bastante diversión cuando todos en el equipo eligen un 3, y alguien anota un 20 y tiene que explicarse, o cuando todos en el equipo anotan un 5 pero el gerente anota un 8 (¿quién va a discutir con él?). el jefe cuando quiere darte más tiempo!).

Para hacer esto, todo lo que necesitas son algunas cartas de póquer de planificación, que a menudo hacemos en el reverso de las fichas o usando naipes normales con valores adjuntos a las figuras.Nada especial y mantiene a todos concentrados.Sólo recuerde que intentar realizar cualquier tarea durante un día entero (incluida la planificación del póquer) afecta la productividad.Muchos juegos de cartas vienen con una tarjeta de café por una razón;Si alguien se siente agotado, ¡dale un descanso al equipo para recargar energías y recógelo cuando todos estén frescos!

Como alternativa a las tarjetas físicas, también puedes mirar tarjetas electronicas.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 otra debido a que puede 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 propia discreción.

Otros consejos

  1. ¿Por qué los elementos de la acumulación no están insertados y priorizados antes del inicio de Sprint? desgastando los desarrolladores El tiempo no es divertido. Deje que su equipo lleve a trabajar con el propietario del producto y el gerente de proyectos unos días antes de priorizar las cosas. Esto va a planificar quién está en cada equipo de Sprint.

  2. ¿Por qué lleva un día para romper las cosas en las tareas? Si tiene un equipo de tamaño razonable (2-4 desarrolladores, .5-1.5 People QA por desarrollador, 1- 2 MISC) Luego, debe tener 2-4 historias de usuario este Sprint. Pase 30 minutos más o menos con los requisitos de aclaración del propietario del producto, luego 30 minutos o así lo rompen a las tareas de ~ 8 horas. No ingrese las tareas durante la reunión. acuerdan solo a un equipo, lo que las tareas son suficientes para que las personas sanas los entiendan, quienes son responsables de ellos, y sobre cuánto tiempo deben tomar. De acuerdo en que "cuánto tiempo deben tomar (incluidas las pruebas)" cabe cómodamente dentro del Sprint.

  3. Si no solo está rompiendo las cosas en las tareas, ¿qué más está haciendo? seguro, las retrospectivas pueden tomar 30-60 minutos, pero serán más cortas a medida que los equipos se metan en una ranura.

    4. En resumen, dejar de perder el tiempo de las personas y temerán las reuniones un poco menos. Más allá de eso, la diversión y la comradarie en el equipo no es algo que puedas abordar en las reuniones. Vaya a almorzar juntos, bromear, mezclar a las personas para que tenga mejores problemas de personalidad, tenga concursos de crecientes de bigote ... Una vez que la moral esté arriba, la gente naturalmente hará que las reuniones de planificación de Sprint sean más fotografíe.

Planificación es un área de Scrum donde los equipos tienen mucha flexibilidad. Intente algo nuevo cada sprint hasta que golpee algo que funcione para su equipo.

Algunas ideas exitosas que he intentado personalmente, o escuchado de otros equipos:

  • Do la creación y la priorización de la historia del usuario sin todo el equipo. El propietario del producto y / o el Scrum Master pueden manejar una gran cantidad de trabajo ocupado y dejar que el equipo lo modifique.
  • Haz que su backlog sea significativamente más largo que un solo Sprint. Puede tomar un tiempo para construirlo, pero si su backlog es lo suficientemente largo, las reuniones de planificación se reducen a hacer pequeños ajustes o abordando los desarrollos de negocios recientes.
  • Tener reuniones de estimación separadas de la planificación de Sprint. Si la gente piensa que las reuniones son demasiado largas, no hay razón para no dividirlos.
  • planifica específicamente los descansos en la agenda. Esto es útil si a menudo está desperdiciando el tiempo a la espera de que uno o dos miembros del equipo regresen.
  • se rompe en el centro de la reunión y asignar a todos a tomar una o dos historias de usuario, luego reunirse para informar y obtener un consenso.
  • Asegúrese de que su reunión de planificación sea sobre qué para hacer, no cómo para hacerlo. Los ingenieros caen muy fácilmente en este último. Si necesita, configure reuniones de diseño separadas donde discuta cómo.
  • Separe sus historias en investigación e implementación. Las reuniones de planificación a menudo pasan demasiado tiempo cuando los miembros del equipo saben muy poco sobre lo que trabajarán, y tratar de resolverlo durante la reunión. Por ejemplo, digamos que necesitaba integrarte con una API que tu equipo no tiene experiencia. con. En lugar de tratar de crear estimaciones y tareas durante la reunión de planificación sobre algo que está despistado, haga una historia de investigación para aprender la API, haga una aplicación simple "Hello World", y enséñela al equipo. luego estará equipado para planificar el trabajo real.
  • Mantener un seguimiento durante sus reuniones de problemas específicos. No solo "la planificación es aburrida", sino también un nivel de detalle, "pasamos mucho tiempo hablando de requisitos poco claros, y nadie parece saber la respuesta correcta". Luego, discuta esas cuestiones específicas en sus retrospectivas y una lluvia de ideas para soluciones específicas. Rompa su problema hasta que las piezas sean fáciles de resolver.

Tenemos nuestra planificación de sprint y retrospectiva al mismo tiempo, y casi siempre se realizan en 90 minutos, pero somos uno de los equipos más rápidos. Hacemos una gran planificación a largo plazo de toda la compañía cada 5 sprints que dura 4-6 horas. Cada equipo es diferente, por supuesto, pero si está pasando un día entero cada sprint, hay mucho espacio para mejorar.

¡Sus sesiones de planificación son demasiado largas!

Según mi experiencia, una reunión de planificación de Sprint debe tomar más de 2 horas por semana que se está planeando (por ejemplo, un Sprint de 2 semanas debe tomar 1/2 día como máximo), pero los exitosos deben ser más cortos que los (la mitad deeso).

En su caso particular: ¿Por qué está estimando tareas?Debe estimar solo historias durante la planificación.Las tareas se pueden estimar más adelante por los propietarios de tareas específicos .

Una forma que funcionó para mí:

  • Introducción rápida al Sprint por el PO
  • estimación de la capacidad Sprint
  • Las historias se agotan y planifican el póquer (TimBoxed a 5/10 minutos por historia) hasta que haya suficientes cosas estimadas para cubrir el Sprint
  • compromiso oficial / pronóstico por parte del equipo

Luego, en paralelo / parejas / auto organizado en nuestros escritorios, tareas y estimaciones de tareas.

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

  • retrospectiva. Comenzamos a hacer esto en la tarde del último día, pero a menudo nos encontramos retrospectivamente sobre el sprint y luego volvimos a trabajar atando los últimos cabos sueltos de ese trabajo de Sprint. Por lo tanto, pensamos que sería mejor asegurarnos de que el trabajo estuviera detrás de nosotros antes de retrospectionarlo. También parecía lógico consolidar toda la reunión superior del proceso Scrum, por lo que los otros días pudieran ser planificados y gastados en términos más ideales. Esto típicamente tomó 2 horas.
  • Sprint PLANIFICACIÓN. El retroceso se estimó durante una reunión de planificación de hitos (que podría ser un día entero en sí mismo tanto para los devs como para el POS), y la POS priorizó antes del principio. de cada sprint. Discutimos cuántos desarrolladores-días que teníamos disponibles (contabilidad de vacaciones, vaca, etc.), agarró el trabajo, pensamos que podríamos hacer fuera de la parte superior de la pila, y rápidamente revisó los requisitos del usuario (previamente comprobados por nuestra bas) a Obtenga un sentido más completo de lo que implicó el trabajo de lo que obtuvimos con la simple descripción de la vista general durante el MPM. Esto típicamente tomó otras 2 horas.
  • Planificación de tareas. Conocer las historias y los criterios de aceptación, rompimos cada historia en tareas de tamaño de mordida estimadas en horas ideales (una hora dedicada al enfocada únicamente al obtener esa tarea "hecha" sin distracciones o obstáculos). La forma en que terminó nuestra escala de puntos que terminó calibrada, un 5 era un desarrollador-Sprint, por lo que un 1 podría ser cualquier cosa y incluir dos días de desarrolladores. Por esa razón, prácticamente todo tuvo que desglosarse para que los miembros del equipo puedan mostrar progreso en el Scrum Board. Este fue otro bloque de 2 horas, con algunos regalos entre este y el siguiente artículo.
  • AAT que se describe. Nuestro POS y BAS no eran programadores y no se codificó. El POS se esconde detrás de un contrato que estipula que entregarían requisitos en forma de una plantilla de Word y funcionarían con la bas para refinarlos en esa forma. BAS entendió el código, pero su tiempo fue puramente análisis y pruebas finales (que requirió que existe el sistema, por lo que podrían registrar sus macros en selenio). Por lo tanto, para verificar que nuestro código cumplirá con los criterios de aceptación cuando haya llegado a eso, tuvimos que escribir nuestros propios AATS que modelan las acciones de la prueba de aceptación de "papel". Por lo general, hicimos esto en el mismo marco de Nunit que utilizamos para pruebas de la unidad e integración (intentamos fitness y no podíamos renunciar 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 de Scrum, no teníamos una planificación de hitos de todo el equipo, y muchas de las que estamos trabajando no tienen 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, ya que es un compromiso de agarrar la parte superior de X ideal de trabajo de la parte superior. Nos salimos con él, por lo menos al menos, porque somos un equipo interno y cada uno de nosotros trabaja personalmente con los usuarios finales de nuestro software para recopilar requisitos y soluciones de diseño. Incluso entonces, la planificación de Sprint es una cosa a la mañana, todos los lunes, y la tarde se pasa a borrar cualquier obstáculo personal para poder iniciar el desarrollo en serio el martes.

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

Direccionando específicamente sus inquietudes:

    Las reuniones

  • son largas - Time-box. Cada reunión, ya sea una planificación retrospectiva, la ruptura de la tarea, etc., debe tener un propósito y un tema definido de discusión, y deben ser limitados tanto como sea posible a un período de tiempo establecido. Es el trabajo de Scrum Master para mantener estas reuniones sobre el tema y rodar para cumplir con los objetivos de tiempo.

  • Las reuniones son monótonos , habrá algo de eso; Estás trabajando en trozos de tamaño muerde, uno a la vez, así que estarás haciendo lo mismo una y otra vez. Mantener el equipo enfocado y conducir hacia el cumplimiento del propósito de la reunión ayudará.

    Algo más que escucho es que tal vez sus reuniones de planificación de Sprint están tratando de lograr demasiado. En mi última empresa, la estimación de la historia se realizó en "Reuniones de planificación de hitos", que ocurrió aproximadamente una vez un cuarto y se tomó todo el día. En esas reuniones, todo lo que se había acumulado en el atraso que no hemos estimado se estimaba en puntos. Si está haciendo una estimación de la historia en puntos, y luego la estimación de la tarea en horas, no quiere hacerlos ambos al mismo tiempo (tal vez el mismo día).

  • Estimando historias en puntos, entonces las tareas en horas parecen redundantes

EM> - 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 llenar su retroceso de sprint en función de la velocidad pasada y el ancho de banda esperado. El propósito de la estimación de la tarea es romper las historias en las cosas que toman un día de desarrollador o menos (y así se pueden asignar a un solo un tipo que se espera que se haga todo lo que se haga a tiempo), y asegúrese de que no haya Se estimó mal la complejidad de cualquier historia ni mordida más de lo que puedes masticar en el sprint.

Si sus historias, todos toman 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 tuvimos muchas épicas para estimar), que en una escala lineal hicieron un punto, cualquier punto hasta 2 días de desarrolladores. Dado ese tipo de escala, prácticamente todo debería dividirse en tareas. En mi nueva compañía, un punto está más cerca de la mitad de un día de desarrollador, por lo que un 1 o incluso un 2 es definitivamente su propia tarea, y 3-8 es nebulosa con respecto a forzar al equipo para dividirlo en tareas.

  • Hay un ciclo vicioso de la que se está volviendo más en caso de hacer que las personas se enfoqueen menos, por lo que se necesita más tiempo - Caja de tiempo en su caja de tiempo. Tome los descansos, al igual que debe ser cuando se codifique. Cada 30 minutos, tome 5 minutos para estirar las piernas, reagruparse, etc. Puede hacerlo diez minutos cada hora, pero no presione un bloque sólido de tiempo de reunión demasiado más lejos que eso. Sus muchachos pueden tener hambre, o necesitan más café, o un descanso de baño, etc. No los niegues; Si los haces chupar, encontrarás sus mentes vagando. Más allá de eso, mantener las discusiones cortas, dulces y al punto, también lo ayudarán, como se mencionó anteriormente.

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

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

      3. La primera parte se basa relativamente en función del número de puntos de historia que el equipo siente que pueden asumir, comprometerse a completar las muchas historias de usuarios en su orden de prioridad.Hecho.

      La segunda parte es lo que los desarrolladores realmente deben disfrutar, la elaboración de la historia y diseñar la solución.Las tareas se caen de eso.Por lo tanto, tenga el propietario del producto, o cualquier pyme que haya proporcionado explique una historia elegida.Luego, tenga el desarrollador que quiera tomarlo, liderar la discusión del diseño.Usa un tablero blanco.Rebotar ideas alrededor.Diviértete.

      Eso es, de verdad.Si las reuniones de diseño no son divertidas, entonces solo hay algo que está mal.

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

    Dividir la reunión.

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

    • backlog aseo
    • Selección de la historia
    • Desglose de la tarea

    Hacemos cada uno en un día diferente, justo después de nuestro scrum diario, tan pronto como se realiza los días diarios, entramos directamente a la actividad de planificación, y luego estamos libres de reuniones (planificadas regulares) el resto del día.

    Entonces, sí, acaluimos nuestra planificación: -O

    Iré a más detalles sobre lo que está involucrado en cada sesión en un segundo, pero déjame explicar cómo llegamos a esto.

    Nosotros, como tú, tuvimos un problema con las verdaderas reuniones de planificación de Sprint. Tuvimos todos los elementos correctos, pero todo solo tomó para siempre y realmente estaba drenando mentalmente y emocionalmente para pasar.

    Luego recibí esta idea después de leer este empresario Insider Artículo sobre el diario de 5 minutos de Pivotal sobre cómo romper nuestras reuniones en sesiones más cortas y hacerlas al comienzo de cada día.

    Me logré el equipo a una retrospectiva. Algunos miembros del equipo le gustaban de inmediato, otros estaban un poco aprensivos, pero luego nuestro interno mencionó un estudio que leía sobre el Técnica de Pomodoro y comenzó a seguir adelante, y eso realmente ayudó a la idea a ganar tracción.

    Así que decidimos probarlo.
    Rompimos nuestra reunión de 2 horas en tres sesiones de 25 minutos. (Sí, eso es Fuzzy Math, pero todos sintieron que nuestras reuniones eran demasiado largas y solo quería hacerlo si ahorramos tiempo).

    y funcionó! Lo hemos estado haciendo durante aproximadamente 6 semanas en dos proyectos separados (6 Sprints Total de dos semanas) y se hace un mundo de diferencia.
    Somos más productivos. Ahorramos un montón de tiempo.
    Obtenemos mejores salidas. Y ya no tememos nuestras reuniones de planificación.

    y honestamente, nuestra caja de tiempo de 25 minutos es bastante floja, algunas sesiones van realmente rápido, como 5-10 minutos en algunas de nuestras sesiones de aseo, y algunas son largas, como cuando terminamos identificando nuevas historias o teniendo que Rompa las historias y vuelva a estimar durante la negociación. En general, sin embargo, generalmente promedia a no más de 1,5 horas para todo el shebang, y creo que es por eso que funciona tan bien.

    en los detalles .....

    Backlog Hooding

    Bastante simple: revisamos las principales historias de prioridad, hable sobre lo que conllevan, y asegúrese de que nuestras estimaciones sean buenas.

    Refinimentaremos historias si es necesario, como decir que estimamos algo hace algo y después de darnos cuenta de lo que realmente tomó una historia similar, podríamos aceptar reestimar. (Utilizamos Puntos de la unidad menos unitarios < / a> Por cierto, y nosotros > No estime las tareas ).

    Además, si el PO ha agregado nuevas historias que él siente que sean de alta prioridad, este es el momento de estimarlos.

    Porque no hacemos la selección de la historia hasta al día siguiente, este proceso le da un poco de tiempo adicional a 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 correr corta con algunos Po's y mucho tiempo con los demás. (Personalmente, creo que es un gran indicador de olor de cómo está su PO)

    Selección de historia

    Obtenga su chris voss en, es hora de negociar.

    En esta reunión, tomamos las principales historias prioritarias y definimos una DOD para cada uno. Negociamos lo que implicará, que implicará y combinar historias según sea necesario, hasta que todos podamos estar de acuerdo en nuestros goles 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 tareas otro día nos permite pasar el tiempo que debemos negociar realmente bien y comprender nuestros compromisos.

    Tareas

    De acuerdo, así que seré el primero en decir, las tareas fueron mi menos Favorita parte de la planificación en nuestras antiguas reuniones de un día.

    Nunca nos golpeamos nuestro paso con esto. Intentamos ahorrar tareas hasta el final de la reunión, pero todos estábamos acabados de drenarse para entonces y fue realmente improductivo. Intentamos definir tareas al mismo tiempo que nuestro DOD durante nuestra negociación, pero la encontramos demasiado distraída y demasiado engorrosa: nos quemaríamos antes de seleccionar todas las historias. Además, fue muy difícil seguir conmutando el enfoque / pensando entre la estimación, la negociación, la selección de la historia y la tarea Generati

    en.Luchamos, y succionamos, y hizo terriblemente nuestras reuniones.

    pero ahora, Al definir el DOD en un día, y no hacer tareas hasta la siguiente, no nos quemamos, siempre estamos en el Mindstate correcto, y nos daUn día entero para marinar en la historia y realmente pensar y entender todas las tareas antes de comenzar.

    Esto solo, IMHO, es un cambiador de juegos total.

    poniéndolo todos juntos.

    Entonces, aquí es lo que parece nuestro horario de ceremonia de Sprint:

    • Lunes - Scrum diario -> Revisión de Sprint
    • martes - Scrum diario -> Backlog Sheinging
    • miércoles - Scrum diario -> Selección de la historia
    • Jueves - Scrum diario -> Tareas
    • Viernes - Scrum diario -> retrospectiva

    Se ha funcionado muy bien para nosotros. Si le das un tiro, me encantaría escuchar 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 pasar a la planificación de la semana que viene. Todo dentro de una hora.

    Esto es, por supuesto, porque descubrimos que en nuestro caso después de Scrum, demasiado estrictamente, solo perdería demasiado tiempo.Esto se debe a que la mayoría de las historias ya se discuten con nuestros miembros del equipo cuando el solicitante crea la historia del usuario.

    Solo estoy diciendo que si su equipo teme planificar reuniones, probablemente debería dejar ir 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 divertido.

    Dar poder al equipo. - es decir, haz que trabajen en cosas que ellos piensan son los más importantes.

    Licenciado bajo: CC-BY-SA con atribución
    scroll top