Realizado por: Mike Cohn

Traducido por: rick@oncedev.com

Imagen propiedad de: https://watisscrum.nl/wp-content/uploads/Sprint-Backlog-5.png

Las implementaciones exitosas de Scrum involucran un puñado de ceremonias importantes. Esto incluye la planificación del Sprint, la revisión del Sprint, el Scrum diario, la retrospectiva del Sprint y más.

A menudo hay mucha confusión acerca de quién participa, cuándo se llevan a cabo estas ceremonias, cuánto puede durar cada una, el propósito de la ceremonia 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. Enlace a la infografía:

https://www.linkedin.com/feed/update/urn:li:activity:6513505354607849472

La Ceremonia de Planificación del Sprint

La planificación del Sprint marca el inicio oficial del mismo. Una vez que comienza esta ceremonia, también lo hace el Sprint.

El Scrum Master, el Product Owner y el equipo de desarrollo son los participantes. Otros pueden asistir en raras ocasiones cuando el Product Owner y el equipo acuerdan que es apropiado. Por ejemplo, si el próximo Sprint incluirá la funcionalidad de desarrollo que mejor se explica por un experto en el tema (que no es el Product Owner), puede ser útil que esa persona asista. Sin embargo, por lo general, este tipo de discusión se realiza mejor fuera de la reunión de planificación real.

La duración de la ceremonia de planificación del Sprint es proporcional a la duración del Sprint. Un Sprint de cuatro semanas debe planearse en no más de 8 horas. Un Sprint de una semana debe planearse en no más de dos horas.

Estos son los cuadros de tiempo (máximos). Recomiendo que los equipos apunten a completar la planificación del Sprint en aproximadamente la mitad del tiempo permitido.

Para iniciar la ceremonia de planificación del Sprint, el Scrum Master traerá datos sobre la velocidad promedio del equipo y la velocidad más reciente. El Product Owner traerá el trabajo atrasado del producto, o al menos los elementos de mayor prioridad en el trabajo acumulado del producto. En muchos equipos, el Product Owner también proporcionará una meta de Sprint borrador, que puede ser revisada en colaboración a través del proceso de planificación.

Los resultados de la planificación del Sprint incluyen un equipo más experimentado y mejor preparado para el próximo trabajo. Resultados adicionales incluyen un registro de Sprint y un objetivo de Sprint acordado durante la planificación.

Scrum diario

El scrum diario, también conocido como el Standup diario, es una ceremonia corta y diaria durante la cual los miembros del equipo sincronizan el esfuerzo. Los Scrum diarios permiten que los miembros del equipo se aseguren de que las personas adecuadas estén trabajando en las cosas correctas en el momento adecuado.

Cada día, cada participante aborda tres temas:

1.       ¿Qué hice ayer para ayudar a lograr el objetivo del Sprint?

2.       ¿Qué voy hacer hoy para lograr el objetivo del Sprint?

3.       ¿Qué, si hubiese algo, está impidiendo o bloqueando el progreso hacia la meta del Sprint?

Las preguntas pueden formularse de muchas maneras diferentes. Por ejemplo, muchos equipos encuentran beneficioso para los participantes describir lo que se logró en lugar de lo que hicieron.

Los participantes incluyen el Scrum Master, el equipo de desarrollo y, en mi opinión, el Product Owner.

Existe un debate dentro de la comunidad Scrum sobre si el Product Owner debería participar. Excusar al Product Owner del Scrum diario crea una separación dentro del equipo en general. Los sentimientos de "nosotros frente a ellos" ya existen en muchas organizaciones. No sé por qué un equipo de Scrum o el Product Owner querrían hacer algo para mejorar aún más esa actitud negativa.

Cada Scrum diario está limitado a un máximo de 15 minutos o una buena técnica es la cantidad de participantes es la cantidad de minutos más un minuto extra, es decir si son 5 personas el Scrum diario sería de 6, si son 8 personas sería de 9 minutos. La intención es que sea una breve actualización y un esfuerzo de sincronización. A diferencia de la planificación del Sprint, no recomiendo tratar de completar un Scrum diario en la mitad del tiempo recomendado. Para la mayoría de los equipos, 5 a 7 minutos simplemente no es suficiente para plantear problemas reales o comprender el trabajo que se está realizando. Cuando los equipos acortan demasiado los Scrum diarios, la ceremonia se convierte en una serie de actualizaciones de memoria, como "Ayer hice tal y cual cosa. Hoy haré esto y aquello. Nada está en mi camino."

No hay insumos formales para el scrum diario. El único resultado es una mayor coordinación del trabajo por parte del equipo de desarrollo.

Ceremonia de Revisión de Sprint

La revisión del Sprint ocurre el último día del Sprint. Debe ser atendido por el Product Owner, el Scrum Master, el equipo de desarrollo y las partes interesadas apropiadas. Los participantes interesados pueden variar de un Sprint a otro en función de lo que se haya entregado.

La revisión del Sprint es un período de cuatro horas como máximo para un Sprint de cuatro semanas. Es proporcionalmente más corto para los Sprint más cortos, hasta una hora para un Sprint de una semana.

Como insumos para la revisión del Sprint, el equipo debe mostrar todos los elementos del Backlog de productos que cumplan con la definición de hecho del equipo. 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 .

El demo de la funcionalidad terminada es la actividad central de una revisión del Sprint típico. Pero la mayoría de los equipos también se tomarán el tiempo para discutir el progreso y los problemas. Puedes leer acerca de mi agenda recomendada para la revisión del Sprint .

El objetivo de la revisión es solicitar comentarios sobre lo que se construyó durante el Sprint. El Product Owner considera todos los comentarios y puede realizar cambios en la cartera de productos según corresponda. El resultado de una revisión de velocidad es, por lo tanto, una acumulación de productos revisada.

Ceremonia Retrospectiva del Sprint

La ceremonia retrospectiva del Sprint es un momento para que los miembros del equipo consideren cómo mejorar su forma de trabajar. Esto significa que pueden cambiar aspectos de la forma en que hacen Scrum, como la longitud de sus Sprint. 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.

A la retrospectiva del Sprint debe asistir todo el equipo , es decir, el equipo de desarrollo, el Scrum Master y el Product Owner. Hacer lo contrario es crear una ruptura dentro del equipo. Un buen equipo Agile debe evitar cualquier comportamiento que conduzca a una mentalidad de nosotros frente a ellos.

No hay aportaciones formales para una retrospectiva del Sprint que no sea la voluntad de mejorar. El resultado es una lista de los cambios que el equipo hará a cómo funciona.

La retrospectiva del Sprint se formaliza dentro de un tiempo de 3 horas. En ocasiones, una retrospectiva puede tomar ese tiempo, pero la mayoría de los equipos realizarán la mayoría de las retrospectivas en una hora.

Refinamiento del Backlog del producto

El refinamiento del Backlog de productos se refiere a asegurar que los elementos en la parte superior del Backlog de productos estén listos para el próximo Sprint. Esto puede incluir agregar detalles a los elementos existentes, estimar, eliminar elementos, ajustar prioridades, dividir elementos del Backlog de productos para encajar mejor dentro de un Sprint y crear nuevos elementos.

Si bien el refinamiento del Backlog 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 Sprint. Sin embargo, la mayoría de los equipos llevarán a cabo reuniones periódicas de refinamiento del Backlog de productos, generalmente una vez por Sprint o una vez por semana.

La guía habitual es gastar no más del 10% del tiempo total disponible de un equipo en el refinamiento del Backlog de productos, tanto en las reuniones como en las discusiones que puedan resultar de esas reuniones.

La mayoría de los equipos tendrán a todo el equipo de desarrollo participando junto con el Product Owner y el Scrum Master. A menos que un equipo esté estimando los elementos del Backlog de productos durante sus reuniones de refinamiento, creo que tal vez la mitad a dos tercios del desarrollo sea suficiente lo que reduce la carga general de tiempo de reunión en un equipo.

Las únicas aportaciones a esta ceremonia son los elementos en la parte superior del Backlog de productos.

Los resultados son elementos del Backlog de productos que a menudo se dividen para ser más pequeños y se ajustan mejor dentro de un Sprint, así como una mayor comprensión de algunos elementos del Backlog de productos.

Estimación del Backlog

Como se señaló anteriormente, muchos equipos estimarán durante las reuniones de refinamiento del Backlog de productos. Ese es el enfoque ideal, y es posible si todo el equipo de desarrollo participa en el refinamiento del Backlog.

Si solo un subconjunto del desarrollo participa en el refinamiento del Backlog, los miembros del equipo se reunirán una vez por Sprint para estimar cualquier nuevo trabajo para el cual el Product Owner pueda necesitar un presupuesto.

Para la mayoría de los equipos, estas ceremonias de estimación deben ser muy cortas. La mayoría de los equipos no deben generar ni recibir una avalancha de nuevos elementos del Backlog de productos en cada Sprint. El trabajo que se debe estimar debe ser importante, los elementos del Backlog de productos nuevos o los elementos existentes que se han dividido para encajar mejor en el próximo Sprint.

Me gusta hacer una estimación del Backlog de productos inmediatamente después de un Scrum diario, un par de días antes del final del Sprint. Esto es lo suficientemente tarde como para que la mayoría de los nuevos artículos se hayan identificado, pero a tiempo para que el Product Owner ajuste las prioridades en función de la nueva información transmitida por las estimaciones.

No recomiendo la estimación durante la planificación del Sprint. Eso es demasiado tarde para que el Product Owner ajuste las prioridades basándose en las estimaciones. También lleva a que los miembros del equipo gastan más de lo que deberían en la estimación. Por lo tanto, no estimes los elementos del Backlog de productos durante la planificación del Sprint .

Priorización

Antes de que comience un nuevo Sprint, el Product Owner se asegura de que la parte superior del Backlog de productos haya sido priorizada. De acuerdo con el Oxford American Dictionary , priorizar significa "poner las tareas, problemas, etc. en orden de importancia, para que pueda lidiar con lo más importante primero".

Esto significa que no es suficiente para una priorización simplemente decir: "Todos son necesarios". O, como me dijo un Product Owner, "se les llama requisitos por una razón: son necesarios".

En la mayoría de los casos, no habrá una ceremonia oficial de priorización. Más bien, esto es algo que el Product Owner hace solo después de las conversaciones con las partes interesadas para comprender sus necesidades y deseos.

La priorización debe ocurrir lo más tarde posible en el Sprint, mientras se asegura de que se realice antes del siguiente Sprint. Esto a menudo significará hacerlo en el último o penúltimo día del Sprint.

Por lo general, la priorización no requiere mucho tiempo. Esto se debe a que el Product Owner generalmente está afinando las prioridades según el progreso y el aprendizaje del Sprint actual en lugar de realizar una re-priorización absoluta de un Backlog de productos completa.

¿Cuándo se llevan a cabo estas ceremonias?

¿Cuándo realiza tu equipo estas ceremonias? ¿Hay otras ceremonias que recomendarías a otros equipos? ¿Tus participantes son iguales a los que he descrito? Por favor comparte tus pensamientos en los comentarios abajo.

Tags: agil scrum reuniondiaria agilismo ceremoniasscrum retrsopectivascrum