Exitoso Melé Las implementaciones involucran un puñado de eventos de dash importantes (también llamados reuniones de dash o ceremonias de dash). Esto incluye reuniones como planificación de dash, revisión de dash, scrum diario, retrospectiva de dash y más.
A menudo hay confusión sobre quién participa, cuándo se llevan a cabo estos eventos, cuánto dura cada uno, el propósito de cada evento y más.
Para reducir la confusión, hemos creado infografías que responden a cada una de estas preguntas para sprints de 1, 2, 3 y 4 semanas.
Planificación de Dash
Él planificación de sprints El evento marca el inicio oficial del dash. Una vez que comienza este evento, también lo hace el dash.
Él Maestro Scrum, dueño del productoy desarrolladores (equipo de desarrollo) todos participan. Otros pueden asistir en raras ocasiones cuando el propietario del producto y el equipo estén de acuerdo en que es apropiado.
Por ejemplo, si el próximo dash incluirá una funcionalidad de desarrollo explicada mejor por un experto en la materia (que no es el propietario del producto), puede ser útil que esa persona asista. Sin embargo, por lo basic, ese tipo de discusión se lleva a cabo mejor fuera de la reunión de planificación actual.
La duración de la ceremonia de planificación del dash es proporcional a la duración del dash. Un dash de cuatro semanas debe planificarse en no más de 8 horas. Un dash de una semana debe planificarse en no más de dos horas.
Estos son cuadros de tiempo (máximos). Recomiendo que los equipos apunten a completar la planificación del dash en aproximadamente la mitad del tiempo permitido.
Como entrada en la planificación del dash, el Scrum Grasp traerá datos sobre el promedio del equipo velocidad y la velocidad más reciente. El propietario del producto traerá la acumulación de productos, o al menos los elementos de mayor prioridad en la acumulación de productos. En muchos equipos, el propietario del producto también proporcionará un borrador del objetivo del dash, que puede revisarse en colaboración durante el proceso de planificación.
Los resultados de la planificación de sprints incluyen un equipo más inteligente y mejor preparado para el próximo trabajo. Las salidas adicionales incluyen un acumulación de dash y un objetivo de dash acordado.
Scrum diario
Él melé diario, también conocido como el standup diario, es un período breve de 15 minutos durante el cual los miembros del equipo sincronizan el esfuerzo de cada día. Los scrums diarios permiten a los miembros del equipo asegurarse de que las personas adecuadas estén trabajando en las cosas correctas en el momento correcto.
Cada día, cada participante aborda tres temas:
- ¿Qué hice ayer para ayudar a lograr el objetivo del dash?
- ¿Qué haré hoy para lograr el objetivo del dash?
- ¿Qué ocurre si algo impide o bloquea el progreso hacia el objetivo del dash?
Las preguntas se pueden formular de muchas maneras. Por ejemplo, a muchos equipos les resulta beneficioso que los participantes describan lo que fue logrado en lugar de lo que ellos hizo.
Los participantes incluyen el Scrum Grasp, el equipo de desarrollo y, en mi opinión, el propietario del producto.
Existe cierto debate dentro de la comunidad Scrum sobre si el propietario del producto debe participar. Excusar al propietario del producto del scrum diario crea una separación dentro del equipo en basic. Los sentimientos de nosotros y ellos ya existen en demasiadas organizaciones. No sé por qué un equipo Scrum o su propietario de producto querrían hacer algo para mejorar aún más esa actitud negativa.
Cada scrum diario está limitado a 15 minutos. La intención es que sea un breve esfuerzo de actualización y sincronización.
A diferencia de la planificación de sprints, no recomiendo tratar de completar un scrum diario en la mitad del tiempo recomendado. Para la mayoría de los equipos, de 5 a 7 minutos simplemente no es tiempo suficiente para plantear problemas reales o comprender el trabajo que se está realizando. Cuando los equipos acortan demasiado los scrums diarios, la ceremonia se convierte en una serie de actualizaciones de memoria, como “Ayer hice tal y tal cosa. Hoy haré esto y aquello. Nada se interpone en mi camino.
No hay entradas formales para el scrum diario. El único resultado es una mayor coordinación del trabajo de los desarrolladores.
Revisión de Dash
Él revisión de carrera El evento ocurre el último día del dash. Deben asistir el propietario del producto, Scrum Grasp, el equipo de desarrollo y cualquier parte interesada apropiada. Los participantes de las partes interesadas pueden variar de un dash a otro en función de lo que se haya entregado.
La revisión del dash está limitada en el tiempo a un máximo de cuatro horas para un dash de cuatro semanas. Es proporcionalmente más corto para sprints más cortos, hasta una hora para un dash de una semana.
Como entrada para la revisión del dash, el equipo debe mostrar todos los elementos de la cartera de productos que cumplen con los requisitos del equipo. definicion de hecho. Esto significa que el equipo no muestra el trabajo que aún está en proceso. A veces, sin embargo, puede valer la pena hacer una excepción a esta regla.
La demostración de la funcionalidad finalizada es la actividad central de una revisión de dash típica. Pero la mayoría de los equipos también se tomarán el tiempo para discutir el progreso y los problemas. Puedes leer sobre mi agenda recomendada para la revisión del dash.
El objetivo de la revisión es solicitar comentarios sobre lo que se construyó durante el dash. El propietario del producto tiene en cuenta todos los comentarios y puede realizar cambios en el Pila de Producto según sea apropiado. El resultado de una revisión de dash es, por lo tanto, una cartera de productos revisada.
Retrospectiva de Dash
El evento retrospectivo del dash es un momento para que los miembros del equipo consideren cómo mejorar su forma de trabajar. Esto significa que pueden cambiar aspectos de cómo hacen Scrum, como la duración de sus sprints.
Pero una retrospectiva también puede cubrir aspectos generales del trabajo conjunto, como prohibir las reuniones matutinas o qué temas son apropiados para discutir en Slack y cuáles requieren una conversación cara a cara.
Él la retrospectiva del dash debe ser atendida por todo el equipo—incluido el Scrum Grasp y el propietario del producto. Hacer lo contrario es crear un cisma dentro del equipo. Un buen equipo ágil debe evitar cualquier comportamiento que conduzca a una mentalidad de nosotros/ellos.
No hay entradas formales para una retrospectiva de dash aparte de la voluntad de mejorar. El resultado es una lista de cambios que el equipo hará en su funcionamiento. Algunos equipos formalizan esta lista como un acumulación de mejoras.
La retrospectiva del dash tiene un límite de tiempo formal de 3 horas. En ocasiones, una retrospectiva puede llevar tanto tiempo, pero la mayoría de los equipos realizarán la mayoría de las retrospectivas en una hora.
Refinamiento de la cartera de productos
El refinamiento de la cartera de productos se refiere a asegurar que los artículos en el parte superior de la cartera de productos están listos para el próximo dash. Esto puede incluir agregar detalles a elementos existentes, estimar, eliminar elementos, ajustar prioridades, dividir los elementos de la cartera de productos (o historias del usuario) para encajar mejor dentro de un dash y crear nuevos elementos.
Si bien el refinamiento de la cartera de productos en sí mismo es necesario, no es obligatorio que un equipo realice el refinamiento como una ceremonia formal o que se realice en cada dash. Sin embargo, la mayoría de los equipos llevarán a cabo reuniones periódicas de refinamiento de la cartera de productos, generalmente una vez por dash o una vez por semana.
La orientación ordinary es no dedicar más del 10 % del tiempo complete disponible de un equipo al perfeccionamiento de la cartera de productos, tanto en reuniones como en debates que puedan derivarse de dichas reuniones.
La mayoría de los equipos tendrán la participación de todo el equipo (incluido el propietario del producto y el Scrum Grasp). A menos que un equipo esté estimando los elementos de la cartera de productos durante sus reuniones de refinamiento, encuentro que tal vez la mitad o dos tercios del desarrollo es suficiente y cut back la carga complete de tiempo de reunión en un equipo.
Las únicas entradas para esta ceremonia son los elementos en la parte superior de la cartera de productos. Los resultados son elementos de la cartera de productos que a menudo se dividen para que sean más pequeños y se ajusten mejor a un dash, así como una mayor comprensión de algunos elementos de la cartera de productos.
Estimación de la cartera de pedidos
Como se señaló anteriormente, muchos equipos estimación durante las reuniones de refinamiento de la cartera de productos. Ese es el enfoque supreme y es posible si todo el equipo de desarrollo participa en el refinamiento de la cartera de pedidos.
Si solo un subconjunto del equipo de desarrollo participa en el refinamiento de la cartera de pedidos, los miembros del equipo se reunirán una vez por dash para estimar cualquier trabajo nuevo para el cual el propietario del producto pueda necesitar una estimación.
Para la mayoría de los equipos, estos eventos de estimación deberían ser muy breves. La mayoría de los equipos no deberían generar o recibir una avalancha de nuevos elementos de la cartera de productos en cada dash. El trabajo a estimar debe ser importante, nuevos elementos de la cartera de productos o elementos existentes que se han dividido para adaptarse mejor al próximo dash.
Me gusta hacer una estimación de la acumulación de productos inmediatamente después de un scrum diario, un par de días antes del remaining del dash. Eso es lo suficientemente tarde como para que se hayan identificado la mayoría de los elementos nuevos, pero a tiempo para que el propietario del producto ajuste las prioridades en función de la nueva información transmitida por las estimaciones.
sí no recomienda estimar durante la planificación del dash. Es demasiado tarde para que el propietario del producto ajuste las prioridades en función de las estimaciones. También hace que los miembros del equipo gasten más de lo que deberían en la estimación. Asi que, no calcule los elementos de la cartera de productos durante la planificación del dash.
Priorización
Antes de que comience un nuevo dash, el propietario del producto se asegura de que se haya priorizado la parte superior de la cartera de productos. Según el Diccionario americano de Oxfordpriorizar significa “poner tareas, problemas, and many others. en orden de importancia, para que pueda ocuparse primero de los más importantes”.
Esto significa que no es suficiente para una priorización simplemente decir: “Todos son necesarios”. O, como me dijo el propietario de un producto, “Se llaman requisitos por una razón: son obligatorios”.
En la mayoría de los casos, no habrá una reunión o ceremonia oficial de priorización. Más bien, esto es algo que el propietario del producto hace solo, a menudo siguiendo conversaciones con las partes interesadas para comprender sus necesidades y deseos.
La priorización debe ocurrir lo más tarde posible en el dash, mientras se asegura de que se realice antes del próximo dash. Esto a menudo significará hacerlo en el último día o dos del dash.
Por lo basic, la priorización no requiere mucho tiempo. Esto se debe a que el propietario del producto suele ajustar las prioridades en función del progreso y el aprendizaje del dash precise en lugar de realizar una nueva priorización complete de una cartera de productos completa.
¿Cuándo realiza estos eventos?
¿Cuándo realiza su equipo estos eventos? ¿Hay otros eventos que recomendarías a otros equipos? ¿Son sus participantes los mismos que he descrito? Por favor, comparta sus pensamientos en los comentarios a continuación.
