5 ceremonias Scrum

Publicaciones

Las 5 ceremonias Scrum: claves para la gestión de procesos

Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective y Sprint Grooming o Refinement

El objetivo de estas ceremonias o eventos es mantener los mínimos necesarios para facilitar que el control empírico de procesos funciona.

Scrum define cinco ceremonias principales para cumplir con el control de sus procesos, todas con un sentido de ser propio que hace que sean imprescindibles para esta metodología.

Aunque el proceder general de algunas compañías es el de adecuar las ceremonias prescritas a sus necesidades y, si bien esto puede tener sentido en algunas organizaciones que cuentan con una larga tradición en otras metodologías, la tímida aplicación de las ceremonias y su exagerada adaptación a la cultura pre-existente en la organización terminan en muchos casos por generar lo mismo que venían produciendo, pero con nuevos nombres que suenan más “Agile”, lo cual suele acabar en sonoros fracasos.

La razón por la que Scrum cuenta con estas cinco ceremonias es la de mantener los mínimos necesarios para facilitar que el control empírico de procesos funciona. El gran problema de adaptar estos eventos o de transformarlos en otra realidad es el de dinamitar uno de los pilares fundamentales de Scrum y, por lo tanto, asumir correr el riesgo al que conlleva. Analicemos a continuación lo que es un Sprint y las ceremonias que van asociadas al mismo:

¿Qué es un Sprint?

Sprint es un contenedor para el resto de eventos de Scrum. El Sprint es continuo, es decir, su duración no debe cambiar mientras está en marcha el desarrollo del producto, y se puede interpretar como una medida de ritmo constante a lo largo del tiempo, permitiéndonos reducir complejidad y comparar resultados a lo largo de diferentes Sprints. El Sprint permite la transparencia, así como inspeccionar y adaptar los otros eventos de Scrum.

Scrum prescribe que un Sprint debe durar 4 semanas más o menos. Aunque es bastante habitual que los equipos Scrum elijan tener Sprints de diversas duraciones según la finalidad perseguida. Cada caso es diferente y es el equipo Scrum el que debe descubrir cuál es su periodo mínimo necesario para generar valor a través de un incremento terminado.Partiendo de la experiencia más inmediata en la implantación de “Agile” a lo largo de diferentes organizaciones, la duración real de los Sprints es la siguiente:

  1. 2 semanas: poco frecuente, generalmente usada en proyectos de I+D o PoCs que requieren de un rápido ciclado para obtener resultados a muy corto plazo.
  2. 3 semanas: frecuente, se asemeja al anterior, pero generalmente en iniciativas de algo más de envergadura.
  3. 4 semanas: lo más frecuente, parece un ritmo adecuado para la mayor parte de los productos.
  4. 5 semanas: frecuente también, aunque es una duración fuera de los estándares de Scrum. Es habitual encontrarnos este escenario en las organizaciones, demandado por los propios equipos Scrum. Resulta muy útil en proyectos que se encuentran en fases iniciales, así como en periodos estimados como menos productivos.

La duración de un Sprint está determinada por el periodo mínimo en que un equipo de desarrollo puede generar valor a través de un incremento determinado. El Sprint es una iteración definida (time boxed) que sirve al desarrollo iterativo e incremental.

La duración del Sprint se determina por un horizonte de planning aceptable, determinado por el propio equipo Scrum junto al Product Owner. No hay fases en Scrum, sólo Sprints. No existen Sprints específicos de testing, hardening, release o análisis.

Un Sprint normal tendría los siguiente eventos o ceremonias:

  1. El Sprint Planning al comienzo del Sprint
  2. Daily Scrums a diario
  3. Un Sprint Review al final del Sprint para inspeccionar el incremento realizado.
  4. Y, finalmente, una Retrospectiva para inspeccionar el equipo y levantar mejoras que se apliquen en el siguiente Sprint.
  5. Adicionalmente se ha incorporado también una reunión de Grooming o Refinement, que sirve para, dentro del Sprint, afinar y aclarar ciertas historias de usuario que pudieron quedar pendientes durante el Sprint Planning.

Todo ocurre en un sólo Sprint y en cada Sprint. La mentalidad de un proyecto por Sprint es uno de los cambios más difíciles de asumir para las organizaciones que están haciendo una transición a esta metodología Agile-Scrum. A diferencia de la gestión tradicional de proyectos, donde un proyecto puede durar meses o años, en Scrum un “proyecto” dura un sólo un Sprint, de modo que todas las tareas necesarias para llevar el proyecto a cabo (como el diseño, la planificación o el testing) se realizan dentro del mismo Sprint, siempre orientado a generar el máximo valor.

En Scrum, los proyectos se financian por cada Sprint y es el product owner quien decide dónde y a qué dedicar los recursos. Entender esto es crítico para asegurar el éxito en el empleo de Scrum en una organización.

1ª ceremonia: Sprint Planning

El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el Backlog del Producto (Product Backlog ) y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente Sprint. Estos Product Backlog Items son los que compondrán el Sprint Backlog.

Durante esta reunión, el product owner presenta el Product Backlog actualizado que el equipo de desarrollo se encarga de estimar, además de intentar clarificar aquellos ítems que crea necesarios.

Si bien en el Sprint Planning participa el equipo Scrum al completo, no participan los stakeholders. En el Sprint Planning se inspeccionan el Product Backlog, los acuerdos de la Retrospectiva, la capacidad y la Definition of Done y se adaptan el Sprint Backlog, Sprint Goal y el plan para poder alcanzar ese Sprint Goal.

El Sprint Planning se divide en dos partes. En la primera parte de la reunión se trata Qué se va a hacer en el siguiente Sprint y, en la segunda parte, se discute el Cómo. La primera parte está organizada y liderada por el product owner, mientras que de la segunda parte se encarga el Development Team. La única labor del Scrum Master es asegurarse de que la reunión existe como parte de Scrum y que se mantiente dentro de las duraciones estimadas.

El Sprint Planning puede durar hasta 8 horas para Sprints de 4 semanas. En la práctica esta ceremonia suele llevar una mañana completa -alrededor de 5 horas- y, sólo si el producto o el Sprint definido por el Product Owner son complejos o están poco claros, se llegan a alcanzar las 8 horas definidas en la metodología. La razón del Sprint Planning es conseguir alineamiento entre negocio y desarrollo de producto en relación a las prioridades.

2ª ceremonia: Daily Scrum

El Daily Scrum, conocido comúnmente sólo como “La Daily”, es una reunión diaria de 15 minutos en la que participa exclusivamente el Development Team.

En esta reunión todas y cada una de las personas del Development Team responden a las siguientes preguntas:

  1. ¿Qué hice ayer para contribuir al Sprint Goal?
  2. ¿Qué voy a hacer hoy para contribuir al Sprint Goal?
  3. ¿Tengo algún impedimento que me impida entregar?

Mucha gente confunde el Daily Scrum con el Standup Meeting, sin embargo, este último es una práctica de eXtreme Programming (XP) orientada a controlar y gestionar el trabajo motivada por un manager, mientras que el primer término, Daily Scrum, hace referencia a la práctica que permite la inspección y adaptación a través de la auto-organización del equipo.

3ª ceremonia: Sprint Review

El Sprint Review es la reunión que ocurre al final del Sprint, generalmente el último viernes del Sprint, donde el product owner y el Develpment Team presentan a los stakeholders el incremento terminado para su inspección y adaptación correspondientes. En esta reunión organizada por el product owner se estudia cuál es la situación y se actualiza el Product Backlog con las nuevas condiciones que puedan afectar al negocio.

El equipo ha pasado hasta cuatro semanas desarrollando un incremento terminado de software que ahora mostrará a los stakeholders. No se trata de una demostración, sino de una reunión de trabajo. El software ya ha sido mostrado y validado junto con el product owner previamente a esta reunión.

Por un lado, se revisará el incremento terminado. Se mostrará el software funcionando en producción y los stakeholders tendrán la oportunidad de hacer cuantas preguntas estimen oportunas sobre el mismo. El software funcionando ha sido validado previamente por el product owner, que se ha encargado de trabajar con el equipo durante el Sprint para asegurarse que cumple con la Definition of Done y, efectivamente, hace que el Sprint Goal sea válido. Si no existe software funcionando, el Sprint Review carece de sentido, aunque en ciertas ocasiones y oportunidades se sigue manteniendo.

El Development Team tiene que tener un papel importante en esta reunión. Muchas veces no es el product owner quien demuestra el incremento producido, sino que son los propios miembros del Development Team quienes lo hacen. Es una buena práctica no sólo el que lo lleven a cabo, sino también el que lo hagan de forma rotatoria y, tras varios Sprints, hayan participado todos.

El equipo de desarrollo comenta posteriormente qué ha ocurrido durante el Sprint, los impedimentos que se han encontrado, así como soluciones tomadas y actualizan a los stakeholders con la situación del equipo. Por último, el product owner actualiza -con la información de negocio recibida en esta reunión- el Product Backlog para el siguiente Sprint.

En contra de lo que comúnmente se cree, el Sprint Review no se trata de una demo para un cliente o para los stakeholders o incluso para el product owner, ni es tampoco una reunión para felicitar al Equipo de Desarrollo. Es una reunión de trabajo, una de las más importantes porque sirve para marcar la estrategia de negocio. La duración estimada en el estándar para un Sprint Review es de 8 horas para un Sprint de 4 semanas, aunque habitualmente estas reuniones se ejecutan en un entorno de entre 2 y 3 horas.

4ª ceremonia: Sprint Retrospective

La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En algunos casos y por comodidad de los equipos, se realiza conjuntamente con el Sprint Planning, siendo la retrospectiva la parte inicial de la reunión.

El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e identificar posibles mejoras para el próximo. Aunque lo habitual es que el Scrum Master sea el facilitador, es normal que distintos miembros del equipo Scrum vayan rotando el rol de facilitador durante la retrospectiva.

Un formato común es analizar qué ha ido bien durante el Sprint, qué ha fallado y qué se puede mejorar. Este formato se puede facilitar pidiendo a los miembros del equipo Scrum que escriban notas –en post-its- para luego agruparlas y votar aquellos ítems más relevantes, dando la oportunidad a todos de hablar y expresar sus inquietudes.

También se utiliza el formato de retrospectiva basado en cinco fases:

  1. Preparar el ambiente: un pequeño ejercicio para romper el hielo.
  2. Recolectar información: durante esta fase, se utilizan actividades para intentar construir una imagen de lo que ha sido el último Sprint, resultando una imagen conjunta de equipo.
  3. Generación de ideas: el equipo intenta generar ideas para identificar acciones que ayuden a mejorar el rendimiento del equipo durante el siguiente Sprint.
  4. Decidir qué hacer: de las ideas generadas, se proponen acciones que el equipo pueda implementar en el próximo Sprint.
  5. Cierre: Una pequeña actividad de cierre, normalmente unida a una evaluación de la propia retrospectiva, ayuda al equipo a decidir hacia dónde dirigirse en próximas ocasiones. Un recordatorio de la mejora continua.

La duración recomendada por Scrum para un Sprint de 4 semanas es de un máximo de 3 horas, aunque habitualmente se destina entre 1 y 2 horas a este evento.

5ª ceremonia: Sprint Grooming o Refinement

El refinamiento del Product Backlog es una práctica recomendada para asegurar que éste siempre esté preparado. Esta ceremonia sigue un patrón similar al resto y tiene una agenda fija específica en cada Sprint. Se estima su duración en 2 horas máximo por semana del Sprint. Es responsabilidad del product owner agendar, gestionar y dirigir esta reunión.

Los participantes de esta reunión son todo el equipo Scrum, así como cualquier recurso adicional que considere necesario el PO y que pueda contribuir a aclarar el requerimiento. Es necesario, por tanto, que antes de la reunión todos conozcan los requerimientos o historias de usuario que van a ser tratados en la misma y sólo asistan aquellos cuya presencia sea estrictamente relevante.

Workflow de un Sprint - Scrum

Puedes encontrar más información al respecto de este y otros temas relacionados con lo que comentamos en el artículo en el site de nuestro colaborador, Jerónimo Palacios. http://jeronimopalacios.com.

Julio Roche

Julio Roche es Specialist Director del área de System Development&Integration, en la práctica de DxD de Deloitte. Profesional con más de 25 años de experiencia en el mundo del desarrollo de soluciones tecnológicas, su labor se encuentra actualmente focalizada en el terreno de la movilidad y la transformación digital, lo que le ha llevado a estar involucrado en procesos de implantación de metodologías ágiles desempeñando todos los roles que estas enumeran. Ha sido Agile Coach&Trainer, Scrum Master, Product Owner y parte del Development Team.