Eventos
En Scrum existen cuatro eventos bien definidos que ayudan a examinar y adaptar el producto a las necesidades que van surgiendo a lo largo de su vida:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
El objetivo que se persique con estos eventos es minimizar la cantidad de reuniones y hacerlas regularmente. Un Sprint tiene una duración que se fija al principio del mismo y es inmutable. Los eventos, sin embargo, tienen una duración máxima pero pueden terminar en cuanto el objetivo se haya alcanzado. De esta manera, se garantiza una dedicación suficiente sin perder tiempo en el proceso.
Sprint
Scrum divide el proceso en Sprints, que tienen una duración de un mes o menos durante el cual se crea un Product Increment "Done", usable y potencialmente entregable. Los Sprints tienen que tener una duración fija y cuando termina un Sprint empieza el siguiente.
Un Sprint contiene y se compone de un Sprint Planning, los Daily Scrum, trabajo de desarrollo, el Sprint Review y el Sprint Retrospective.
Durante el Sprint:
- No se hacen cambios que pongan en peligro el Sprint Goal.
- La calidad de los objetivos no disminuye.
- El alcance puede ser clarificado y renegociado entre el Development Team y el Product Owner con el conicimiento adquirido.
Cada Sprint puede verse como un proyecto que no va más allá de un mes. Como cualquier proyecto, un Sprint se usa para conseguir algo. Cada Sprint debe tener como objetivo algo que tiene que construirse, un diseño y plan flexible que guíen su construcción, el trabajo y el Product Increment resultante.
Cuando un Sprint dura demasiado, existe la posibilidad de que se difumine la definición de aquello que se quiere construir, que crezca la complejidad y que aumente el riesgo. Los Sprints permiten aumentar la predecibilidad al inspeccionar y adaptar el progreso hacia el Sprint Goal al menos una vez al mes. Además, se limita el riesgo y el coste a un mes de trabajo.
A pesar de la duración fija de un Sprint, éste puede ser cancelado si deja de tener sentido el Sprint Goal fijado, si se da esta casuistica, se termina el Sprint antes de la fecha prevista y se procede como si terminara un Sprint normal.
Sprint Planning
Durante el Sprint Planning se planifica el trabajo a realizar en el Sprint. Esta planificación se realiza de forma colaborativa entre todo el Scrum Team.
El Sprint Planning tiene un limite de 8 horas para un Sprint de un mes (que se ajustará de forma proporcional dependiendo de la duración del Sprint).
El Sprint Planning tiene como objetivo responder a estas dos cuestiones:
- ¿Qué se puede entregar como Product Increment ?
- ¿Cómo vamos a trabajar para entregar el Product Increment?
¿Qué se va a entregar?
El Development Team trabaja para estimar la funcionalidad que se podrá desarrollar durante el Sprint.
El Product Owner habla sobre el objetivo y propone los Product Backlog Items que, a su juicio, servirían para conseguirlo. El Scrum Team colabora para entender cual va a ser el trabajo a realizar durante el Sprint.
El input de este evento son cuatro elementos:
- El Product Backlog.
- El Product Increment anterior.
- La capacidad del equipo para este Sprint.
- El rendimiento hasta ahora del Development Team.
Teniendo en cuenta estas variables es decisión del Development Team y solo suya la cantidad de Product Backlog Items que se van a abordar durante el Sprint. Solo el Development Team puede evaluar que se puede hacer.
Durante el Sprint Planning, el Scrum Team, llega a la conclusión de cual debería ser el Sprint Goal. El Sprint Goal es el objetivo que se intentará conseguir al implementar los Product Backlog Items y es la razón que guía al Development Team a construir el Product Increment.
¿Cómo vamos a trabajar?
Una vez que se han seleccionado los Product Backlog Items para el Sprint, el Development Team decide como se van a construir para conseguir un Product Increment. Este conjunto de Product Backlog Items, junto con el plan para entregarlos, forman el Sprint Backlog.
Normalmente, el Development Team, empieza diseñando el sistema y el trabajo necesario para convertir el Sprint Backlog en un Product Increment. El trabajo puede variar en tamaño, sin embargo, siempre se planifica suficiente trabajo para todo el Sprint. El trabajo planificado para los primeros días del Sprint debe descomponerse al final de este evento, normalmente en trabajo para un día o menos. El Development Team se autoorganiza para hacerse cargo del trabajo en el Sprint Backlog tanto durante el Sprint Planning como cuando sea necesario a lo largo del Sprint.
El Product Owner puede ayudar a clarificar los Product Backlog Items seleccionados y negociar intercambios. Si el Development Team determina que es demasiado o muy poco trabajo, se pueden renegociar los Product Backlog Items con el Product Owner.
Al final del Sprint Planning, el Development Team debería ser capaz de explicar al Product Owner y al Scrum Master como tienen pensado trabajar para conseguir el Sprint Goal y crear el Product Increment.
Sprint Goal
El Sprint Goal es el objetivo fijado para el Sprint que se puede conseguir al implementar el Product Backlog. Sirve de guía para el Development Team, dando respuesta a la pregunta ¿Por qué estamos creando este Product Increment? Este Sprint Goal se crea durante el Sprint Planning y dá al Development Team algo de flexibilidad en relación a la funcionalidad a implementar durante el Sprint. La selección de los Product Backlog Items se puede transformar en una funcionalidad coherente que puede dar como resultado el Sprint Goal. El Sprint Goal puede ser otro motivo más para que el Development Team trabaje unido en lugar de en iniciativas separadas.
El Development Team tiene en mente cual es el Sprint Goal y es por esa razón por la que se crea tecnología y se implementan las funcionalidades. Si le trabajo acaba siendo algo diferente a lo que el Development Team esperaba que fuera, tanto el Development Team como el Product Owner negocial el alcance del Sprint Backlog durante el Sprint.
Daily Scrum
La Daily es un evento para el Development Team. Dura 15 minutos, es a la misma hora y en el mismo lugar todos los días con la finalidad de reducir la complejidad. Durante este evento el Development Team planifica el trabajo a realizar durante el las siguientes 24 horas. Con este evento se pretende mejorar la colaboración y el rendimiento del equipo examinando el trabajo realizado desde la última daily y estimando el trabajo a realizar hasta la siguiente.
El Development Team usa la Daily para examinar cual es el progreso que se ha conseguido hasta el momento con la intención de conseguir el Sprint Goal y completar el Sprint Backlog. La Daily aumenta la probabilidad de conseguir el Sprint Goal. Cada día, el Development Team debería pensar como puede trabajar en conjunto y de forma autoorganizada para conseguir el Sprint Goal y crear el esperado Product Increment antes de que acabe el Sprint.
La forma en la que se desarrolla la Daily la decide el Development Team y puede conducirse de diferentes maneras, siempre que se centre en el progreso hacia el Sprint Goal. Algunos Development Team usan preguntas, otros se basan en debates. Un ejemplo de las preguntas que se pueden usar son las siguientes:
- ¿Qué hice ayer para ayudar al Development Team a conseguir el Sprint Goal?
- ¿Qué voy a hacer hoy para ayudar al Development Team a conseguir el Sprint Goal?
- ¿He visto algun impedimento que nos impide a mi o al Development Team en su conjunto llegar a conseguir el Sprint Goal?
Los miembros del Development Team, a menudo, se reunen inmediatamente después de la Daily para discutir algún detalle, para adaptar o replanificar el resto del trabajo del Sprint.
El Scrum Master debe asegurar que el Development Team tiene la reunión pero es el Development Team el responsable de conducirla. El Scrum Master procura que la reunión se ajuste al tiempo establecido para la reunión (15 minutos).
La Daily es una reunión interna del Development Team. Si se presenta alguien que no es miembro del Development Team en la Daily, el Scrum Master debe asegurarse de que no interrumpe la reunión.
Este evento mejora la comunicación, elimina otras reuniones, identifica impedimentos para eliminarlos, resalta y promueve la rápida toma de decisiones, y mejora el nivel de conocimiento del Development Team.
Sprint Review
El Sprint Review tiene lugar al final del Sprint para examinar el Product Increment y adaptar el Product Backlog si es necesario. Durante el Sprint Review, el Scrum Team y los clientes colaboran sobre lo que se ha hecho en el Sprint. En base a eso y a los cambios del Product Backlog durante el Sprint, los participantes colaboran para encontrar lo siguiente que se puede hacer que aporte más valor. Esta reunión es informal y no se trata de saber cual es el estado del producto, sino de presentar el Product Increment con el objetivo de conseguir obtener feedback y fomentar la colaboración.
Este evento tiene un límite de tiempo de cuatro horas para un Sprint de un mes de duración. Para Sprints más cortos la duración seria menor. El deber del Scrum Master es asegurarse de que el evento tiene lugar y que los participantes entiendan cual es el proposito de este evento, además de procurar que se cumpla con el límite de tiempo establecido.
El Sprint Review incluye los siguientes elementos:
- Los participantes son los miembros del Scrum Team y los stakeholders a los que invite el Product Owner.
- El Product Owner explica que Product Backlog Items están "Done" y cuales no.
- El Development Team discute que es lo que fué bien durante el Sprint, con que problemas se encontraron y cuales son los problemas que solucionaron.
- El Development Team hace una demostración del trabajo que está "Done" y responde a las preguntas sobre el Product Increment.
- El Product Owner presenta el Product Backlog tal y como está, propone objetivos y fechas de entrega basadas en el progreso hasta la fecha (si es necesario).
- Todos los presentes colaboran para decidir que será lo proximo que se debería hacer, facilitando de esta forma el trabajo que se realizará en el siguiente Sprint Planning.
- Revisar como el mercado o el uso potencial puede haber cambiado y qué es lo que aportará mayor valor.
- Revisar los plazos, el presupuesto, la competencia potencial, y el mercado, para las siguientes funcionalidades y capacidades del producto.
El resultado de un Sprint Review es una revisión del Product Backlog que tiene bien definidos los Product Backlog Items para el siguiente Sprint. Además el Product Backlog debería incluir elementos que busquen nuevas oportunidades.
Sprint Retrospective
El Sprint Retrospective es una oportunidad que tiene el equipo para examinarse a si mismo y crear un plan de acción para mejorar durante el siguiente Sprint.
El Sprint Retrospective se realiza después del Sprint Review y antes del siguiente Sprint Planning y dura hasta tres horas en un Sprint de un mes de duración. Con Sprints más cortos la duración será menor. El Scrum master se asegura de que el evento tiene lugar y que los participantes saben cual es su propósito.
El Scrum Master se asegura de que la reunión es positiva y productiva, de que la reunión tenga la duración fijada y participa como un miembro más del Scrum Team desde la responsabilidad sobre el proceso Scrum.
El proposito del Sprint Retrospective es:
- Examinar como fué el último Sprint con respecto a la gente, las relaciones, los procesos y las herramientas.
- Identificar y ordenar los elementos más destacables que fueron bien y las mejoras potenciales.
- Crear un plan para implementar las mejoras que pongan en camino al Scrum Team para hacer su trabajo.
El Scrum Master anima al Scrum Team a mejorar, en el framework Scrum, su proceso de desarrollo y practicas para hacermas efectivo y llevadero el siguiente Sprint. Durante cada Sprint Retrospective, el Scrum Team planifica formas de incrementar la calidad del producto, mejorando los procesos de trabajo o adaptando la definición de "Done", si es apropiado y no entra en conflicto con el producto o los estándares de la organización.
Al final del Sprint Retrospective, el Scrum Team debería haber identificado mejoras que implementarán en el siguiente Sprint. Implementar estas mejoras en el siguiente Sprint es la forma de adaptar lo que el Scrum Team a descubierto sobre si mismo. Aún que las mejoras se pueden implementar en cualquier momento, el Sprint Retrospective es una gran oportunidad para centrarse en la inspección y la adaptación.
Más información
La fuente de información principal es la Scrum Guide. En el sitio oficial de Scrum se puede encontrar información relacionada con Scrum así como todo lo necesario para poder certificarse en los diferentes roles definidos en la guía.