Saltar al contenido principal
Página

Tema 4.8 - Reuniones o Ceremonias de Scrum

Eventos Scrum 



Para que cualquier proyecto tenga éxito, la comunicación es importante. Los Scrum Teams emplean una serie de reuniones clave para estructurar el trabajo del equipo: 

● Los Sprints

● Sprint Planning (Planificación del Sprint)

● Daily Scrum (Scrum Diario)

● Sprint Review (Revisión del Sprint)

● Sprint Retrospective (Retrospectiva del Sprint)



El Sprint


El Sprint es un contenedor para todos los eventos.


Eventos de Scrum

Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los artefactos de Scrum.

Estos eventos están diseñados específicamente para habilitar (permitir) la transparencia requerida (necesaria).

Si no se realizan los eventos según lo prescrito, se pierden oportunidades para inspeccionar y adaptarse.


Los eventos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.

Lo óptimo es que todos los eventos se celebren al mismo tiempo y en el mismo lugar para reducir la complejidad.


El Sprint

Los Sprints son el corazón de Scrum, donde las ideas se convierten en valor.

Son eventos de duración fija de un mes o menos para crear consistencia.


Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.


Todo el trabajo necesario para alcanzar el objetivo del producto, incluyendo la Planificación (Sprint Planning), Daily Scrums, Revisión del Sprint (Sprint Review ) y la Retrospectiva (Sprint Retrospective),  ocurren dentro del Sprints.


Durante el Sprint:

● No se realizan cambios que pongan en peligro el Objetivo del Sprint

● La calidad no disminuye

● El Product Backlog se refina según sea necesario

● El alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende más 

Los Sprints permiten la previsibilidad al garantizar la inspección y adaptación del progreso hacia un Objetivo del Producto al menos cada mes calendario.


Cuando el horizonte de un Sprint es demasiado largo, el Objetivo del Sprint puede volverse inválido, la complejidad puede crecer y el riesgo puede aumentar. 

Se pueden emplear Sprints más cortos para generar más ciclos de aprendizaje y limitar el riesgo de costo y esfuerzo a un período de tiempo menor.

Cada Sprint puede considerarse un proyecto corto.

Existen varias prácticas para pronosticar el progreso, como gráficos de burn-downs, burn-ups, o flujos acumulativos.


Si bien han demostrado ser útiles, estos no sustituyen la importancia del empirismo. En entornos complejos, se desconoce lo que sucederá. Solo lo que ya ha sucedido se puede utilizar para la toma  de decisiones con vistas a futuro.

Un Sprint podría cancelarse si el Objetivo del Sprint se vuelve obsoleto.

Solo el Product Owner tiene la autoridad para cancelar el Sprint.


Sprint Planning-Planificación de Sprint

La Sprint Planning inicia el Sprint al establecer el trabajo que se realizará para el Sprint.


El Scrum Team crea este plan resultante mediante trabajo colaborativo.


El Product Owner se asegura de que los asistentes estén preparados para discutir los elementos más importantes del Product Backlog y cómo se relacionan con el Objetivo del Producto.


El Scrum Team también puede invitar a otras personas a asistir a la Sprint Planning para brindar (proporcionar) asesoramiento.

La planificación del Sprint aborda los siguientes temas:


Tema Uno: ¿Por qué este Sprint es valioso?

● El Product Owner propone cómo el producto podría Incrementar su valor y utilidad en el Sprint actual

● A continuación, todo el Scrum Team colabora para definir un objetivo de Sprint que comunique por qué el Sprint es valioso para las partes interesadas

● El Objetivo del Sprint debe completarse (finalizarse) antes de que termine la Sprint Planning


Tema dos: ¿Qué se puede hacer en este Sprint?

● A través de una conversación (discussion en Inglés) con el propietario del producto (Product Owner), los desarrolladores seleccionan los elementos del Product Backlog para incluir en el Sprint actual.

● El equipo de Scrum puede refinar estos elementos durante este proceso, lo que aumenta la comprensión y confianza

 ● Seleccionar cuánto se puede completar dentro de un Sprint puede ser un desafío

● Cuanto más sepan los Developers sobre su desempeño pasado, su capacidad actual (upcoming capacity en Inglés) y su Definición de Terminado, más confiados estarán en sus pronósticos para  el Sprint



Fuente: https://miro.com/blog/resources/visual-collaboration-agile-development-guide/product-backlog


Tema tres: ¿Cómo se realizará el trabajo elegido?

● Para cada elemento del Product Backlog seleccionado, los Developers planifican el trabajo necesario para crear un Incremento que cumpla con la Definición de Terminado

● Normalmente esto se hace descomponiendo los elementos del Product Backlog en elementos de trabajo más pequeños de un día o menos

● La forma de hacerlo queda a criterio exclusivo de los Developers. Nadie más les dice cómo convertir los elementos del Product Backlog en Incrementos de valor


Sprint Backlog

El Objetivo del Sprint (Sprint Goal), los elementos del Product Backlog seleccionados para el Sprint, más el plan para entregarlos se denominan juntos Sprint Backlog.





La Sprint Planning tiene un límite de tiempo de máximo ocho horas (timeboxed) para un Sprint de un mes.

Para Sprints más cortos, el evento suele ser de menor duración.



Daily Scrum (Scrum Diario) 

El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario, ajustando el próximo trabajo planeado.

El Daily Scrum es un evento de 15 minutos (máximo) para los desarrolladores del equipo de Scrum.

El Daily Scrum no es la única vez que los desarrolladores pueden ajustar su plan.

Frecuentemente se reúnen durante todo el día para debatir (discusiones) de forma más detalladas sobre la adaptación o volver a planificar del resto del trabajo del Sprint.


Para reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint.


Si el Product Owner o Scrum Master están trabajando activamente en elementos del Sprint Backlog, participan como Developers.

Los Developers pueden seleccionar la estructura y las técnicas que deseen, siempre que su Daily Scrum se centre en el progreso hacia el Objetivo del Sprint y produzca un plan viable para el siguiente  día de trabajo.

Esto crea enfoque y mejora la autogestión.

Las Daily Scrums mejoran la comunicación, identifican impedimentos, promueven la toma rápida de decisiones y, en consecuencia, eliminan la necesidad de otras reuniones.


Aspectos Adicionales - Daily Scrum (Scrum Diario)


 


● El equipo se reúne para comunicar y entender los estados

● Esencial para conocer el progreso continuo y evitar bloqueos

● No tiene como objetivo reportar progreso





Revision del Sprint (Sprint Review)

El propósito de la Sprint Review es inspeccionar el resultado del Sprint y determinar futuras adaptaciones.

El Scrum Team presenta los resultados de su trabajo a los interesados clave y se discute el progreso hacia el Objetivo del Producto.

El Scrum Team y los interesados revisan lo que se logró en el Sprint y lo que ha cambiado en su entorno.

Con base en esta información, los asistentes colaboran sobre qué hacer a continuación.

El Product Backlog también se puede ajustar para satisfacer nuevas oportunidades.

La Sprint Review es una sesión de trabajo y el Scrum Team debe evitar limitarla a una presentación.

La Sprint Review es el penúltimo evento del Sprint y tiene un límite de tiempo de máximo cuatro horas (timeboxed) para un Sprint de un mes.

Para Sprints más cortos, el evento suele ser de menor duración.


La Retrospectiva del Sprint (Sprint Retrospective)

El propósito de la Sprint Retrospective es planificar formas de aumentar la calidad y la efectividad.

El Scrum Team inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado.

Los elementos inspeccionados suelen variar según el ámbito del trabajo.

Se identifican los supuestos que los llevaron por mal camino y se exploran sus orígenes.

El Scrum Team analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.

El Scrum Team identifica los cambios más útiles para mejorar su efectividad.

Las mejoras más impactantes se abordan lo antes posible.

Incluso se pueden agregar al Sprint Backlog para el próximo Sprint.

La Sprint Retrospective concluye el Sprint.

Tiene un tiempo limitado a máximo tres horas para un Sprint de un mes.

Para Sprints más cortos, el evento suele ser de menor duración.


Técnicas para Conducir una Retrospectiva


● El barco de vela (The sailboat)

● Las 4L Technique

● La Estrella de Mar (Starfish)

● Mad-Sad-Glad

● Start-Stops-Continue

Recomendadohttps://www.mural.co/templates/retrospective

                          https://www.smartsheet.com/content/retrospective-templates


Las 5 Etapas de una Retrospectiva


Daily Standup Meeting



   

¿Qué puede ser terminado? 

Esta pregunta nos ayuda para que el Development Team (DT) trabaje para proyectar la funcionalidad que se desarrollará durante el Sprint, donde se define objetivo del Sprint (Sprint Goal). 

El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Development Team (DT).


Sprint Goal





  • El Sprint Goal es una meta establecida para el Sprint que puede lograrse mediante la implementación del Product Backlog. 
  • El Sprint Goal brinda al Development Team cierta flexibilidad con respecto a la funcionalidad implementada en el Sprint. 
  • El Sprint Goal puede representar otro nexo de unión que haga que el Development Team trabaje en conjunto y no en iniciativas separadas.



¿Cómo se conseguirá completar el trabajo seleccionado?

Una vez que se ha establecido el Sprint Goal y seleccionado los elementos del Product Backlog para el Sprint, el Development Team decide cómo construirá esta funcionalidad para formar un Incremento de producto “Done” durante el Sprint. 

Los elementos del Product Backlog seleccionados para este Sprint, más el plan para terminarlos, recibe el nombre de Sprint Backlog. Esta pregunta nos ayuda para que el Development Team (DT) trabaje para proyectar la funcionalidad que se desarrollará durante el Sprint, donde se define objetivo del Sprint (Sprint Goal). El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Development Team (DT).


Sprint Review Meeting 

  • Los asistentes son el Scrum Team y los stakeholders claves invitados por el Product Owner. 
  • El Product Owner explica qué elementos del Product Backlog se han “Done” y cuales no se han “Done”. 
  • El Development Team habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas. 
  • El Development Team hace una demostración del trabajo que ha “Done” y responde preguntas acerca del Incremento. 
  • El Product Owner habla acerca del Product Backlog en su estado actual. Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el progreso obtenido hasta la fecha (si fuera necesario). 
  • El grupo completo colabora acerca de qué hacer a continuación, de modo que el Sprint Review proporcione información de entrada valiosa para el subsiguiente Sprint Planning. 
  • Revisión de cómo el mercado o el uso potencial del producto podría haber cambiado lo que es de más valor para hacer a continuación.
  • Revisión de la línea de tiempo, presupuesto, capacidades potenciales y mercado para las próximas entregas de funcionalidad o capacidad prevista del producto.



Sprint Retrospective 



  • El Sprint Retrospective es una oportunidad para el Scrum Team de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint. 
  • El Sprint Retrospective tiene lugar después del Sprint Review y antes del siguiente Sprint Planning.
  • Se trata de una reunión de, a lo sumo, tres horas para Sprints de un mes. 

El propósito del Sprint Retrospective es: 

  • Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas.
  • Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras. 
  • Crear un plan para implementar las mejoras a la forma en la que el Scrum Team desempeña su trabajo. 




Última modificación: lunes, 22 de noviembre de 2021, 11:20