Scrum Guide, segunda lectura

Cortesía de Pixabay

Hace ya un par de años escribí un artículo donde resumía la Guía de Scrum. Ese artículo se centraba más en la parte técnica de ejecución de Scrum. Hoy he vuelto a realizar una segunda lectura y he descubierto detalles que se me escaparon en su momento.

Scrum está creado sobre la teoría del control de procesos empírico y en la toma de decisiones basada en lo que se conoce.

La teórica de control de procesos empírico se soporta en tres pilares:

• Transparencia:  
• Los aspectos más relevantes del proceso deben ser visibles para los responsables del resultado. 
• Estos aspectos han de definirse mediante un estandar de manera que los observadores compartan el entendimiento de los datos. 
• Inspección: 
• Se debe inspeccionar frecuentemente los artefactos de Scrum y su progreso hacia el Objetivo de Sprint para detectar variaciones indeseadas. 
• Adaptación: 
• Si se detecta una variación más grande de lo asumible es necesario realizar acciones de ajuste lo antes posible. 
• Los cuatro eventos de Scrum están pensados para inspeccionar y adaptar.

La guía indica que si los equipos de desarrollo adoptan y se guían por los valores de Compromiso, Coraje, Foco, Apertura y Respecto los tres pilares (transparencia, inspección y adaptación) se cumplirán. 

Hay un párrafo que define y enlaza muy bien los valores de Scrum en la guía y por ello lo voy a poner traducido: las personas han de comprometerse personalmente a conseguir los objetivos. Los miembros del Scrum Team tienen el coraje de decir las cosas correctas y trabajan en resolver los problemas. Todo el mundo está enfocado en los objetivos. El Scrum Team y los interesados estarán abiertos a los retos que puedan llegar. Los miembros del Scrum Team se respetan entre si sobre su capacidad y su independencia. 

El Equipo

Todos sabemos que el Scrum Team está compuesto por el Producto Owner, el Equipo de Desarrollo y el Scrum Master. Pero hay algunas cosas de estos roles que se me habían pasado por alto en esa primera lectura:

• El PO y el SM pueden ser miembros del Equipo de Desarrollo.
• El PO puede delegar sus tareas en el Equipo de Desarrollo (en detrimento de su capacidad), aunque no puede delegar su responsabilidad.
• El PO es el único que puede cancelar un Sprint si su objetivo ya no tiene sentido, si bien se puede ver influenciado por interesados o el Equipo de Desarrollo.
• Sí sabíamos que no había títulos dentro del Equipo de Desarrollo, pero en una primera lectura me salté por alto algo que después es lógico y obvio y que se fomenta con los perfiles T: los miembros del Equipo de Desarrollo pueden tener habilidades distintas donde están enfocados, pero la responsabilidad del objetivo del Sprint es compartida.
• El tamaño del Equipo de Desarrollo que se indica, de 3 a 9 personas, es una recomendación, nunca una restricción.
• El Scrum Master no facilita todos los eventos de manera sistemática, sólo facilitará aquellos eventos que se le solicite o necesite.

Los eventos

Todos los eventos están pensados para inspeccionar y adaptar, eso implica que puede haber cambios sobre el trabajo que se está haciendo en cualquiera de ellos.

Lo más importante del Sprint es el objetivo, tanto es así que la guía dice que durante el Sprint:

• No puede haber cambios que ponga en peligro el objetivo.
• La calidad de los objetivos no debe bajar.
• El alcance puede ser re-negociado entre el Equipo de Desarrollo y el Product Owner según se va aprendiendo.

El objetivo del Sprint debe ser construido guiado por un diseño y un plan de ejecución flexible.

De aquí yo deduzco que los Product Backlog Items (PBI) son secundarios y sólo un medio para alcanzar el objetivo. Por tanto, si en el camino aprendemos algo que nos lleva a cambiar, descartar o incluir PBIs en favor del objetivo debemos hacerlo. 

Es algo que ya intuía que debía de ser así con el fin de tener el mejor producto del mundo, pero que no había visto que estaba tan claro puesto en la Guía de Scrum. Así, durante el Spring se garantiza la inspección y adaptación, aunque es importante remarcar que esta inspección y adaptación se hará durante la reunión diaria.

En Scrum son 4 los eventos que están diseñados para inspeccionar y adaptar:

• Sprint planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Cuando un Sprint es cancelado el PO decide que hacer con los PBI que están terminados, si bien lo normal hacer una Review de ellos.

Durante la primera parte de la planificación del Sprint el PO presenta el objetivo del Sprint y los PBI que deberían desarrollarse para cumplirlo. Después entre todo el Scrum Team se discute a fin de entender el objetivo y los PBIs.

Durante la segunda parte, el Equipo de Desarrollo trabaja para elaborar el plan más detallado que pueda de cómo va a conseguir cumplir el objetivo. Si ve que no es abordable negociará con el PO a fin de tener un alcance asumible durante el Sprint.

Los PBI deben formar en su conjunto una funcionalidad coherente con el Objetivo del Sprint. Trabajar en un objetivo común y tener los PBI alineados con este objetivo hace que el Equipo de desarrollo se focalice y trabajen juntos en vez de trabajar cada uno en iniciativas separadas.

La Daily es una reunión que va a permitir disminuir la complejidad en la comunicación en los equipos. En la propia guía indica que cada equipo la puede estructurar como más útil le resulte, en forma de narrativa, preguntas u cualquier otro formato. Sin embargo, el objetivo de esta reunión es planificar las siguientes 24h (ya serán 8 :P). 

También se escribe específicamente que muchos equipos después de la Daily hacen otra reunión para entrar en detalles, adaptar cosas que se consideren necesarias, replanificar el resto del Sprint o cualquier otro contenido que se haya visto necesaria durante la Daily.

El objetivo del Sprint Review es inspeccionar el último Incremento desarrollado y adaptar el Product Backlog. Algunas de las cosas que hay que hacer son:

• El PO explica que PBIs han sido terminados y cuales no.
• El Equipo de Desarrollo comentarán que ha ido bien y que ha ido mal durante el Sprint.
• El Equipo de Desarrollo demostrará el trabajo realizado.
• El PO presenta el Product Backlog y cuál será el progreso en función del avance actual.
• Todos los asistentes conversan sobre qué debería ser lo siguiente y cuyas conclusiones serán tenidas en cuenta en la siguiente planificación.

Durante la retrospectiva el Scrum Team definirá un plan para enriquecer la calidad de su producto a través de la mejora del proceso o modificación del "Definition of Done" (si no entra en conflicto con el de la compañía).

Artefactos

El Product Backlog es una definición viva del futuro del producto, está compuesto por PBIs. En la Guía de Scrum se define qué tipo de elementos entran dentro de un PBI:

• Características
• Funciones
• Requisitos
• Mejoras
• Correcciones

Así como los campos mínimos que han de tener:

• Descripción
• Orden
• Estimación
• Valor
• Opcional:
• Descripciones de pruebas
• Añadidos al Definition of Done

Si varios equipos trabajan sobre el mismo producto éstos compartirán el Product Backlog.

El refinamiento del Product Backlog es la acción de añadir detalle, estimaciones y ordenación en los elementos del producto. Será el Scrum Team quien defina cuando parar de refinar. Es importante remarcar que en la Guía no se indica que el refinamiento no deba ser mayor al 10% de la capacidad del Equipo de Desarrollo, lo que indica es que no suele ser más del 10%.

El Sprint Backlog tiene dos partes, la primera es el conjunto de PBI seleccionados para ser abordados en el Sprint y la segunda es el plan para desarrollar el incremento y alcanzar el Objetivo del Sprint.

Se hace énfasis en incluir en el Sprint Backlog al menos uno de los elementos identificados en durante la Retrospectiva. Muchas veces he oído que es necesario incluirlo como un PBI, sin embargo, si el Sprint Backlog tiene también la planificación, entonces ¿será válido también incluirlo en la planificación y no como PBI?

El plan que se defina en el Sprint Backlog debe ser lo suficientemente detallado como para que sea entendible durante una Daily, es decir, que todo el Equipo de Desarrollo sepa el estado de avance del Sprint.

Además este plan estará vivo y será modificado en función de los aprendizajes del equipo durante el transcurso del Sprint.

Espero que os haya gustado y hayáis aprendido algo igual que yo.

Un saludo,

Rubén Álvarez