Ingredientes de SCRUM

1 - Producto

Es el software que se construye durante el proyecto.

2 – Propietario de producto

Persona que se ocupa del producto. ¿Qué funcionalidades debe tener? ¿Cómo será más competitivo? ¿Qué mejoras se le pueden aplicar? Etc.

3 –Scrum master

Persona que se ocupa del proceso es decir, de que se utilice el método Scrum adecuadamente y que el trabajo de los equipos fluya evitando impedimentos.

4- Historias de usuario

Es la descripción de lo que el producto debe hacer.  Es decir, recopilan el conjunto de funcionalidades y otras características que se espera tenga el software que se va a construir.

5 – Puntos historia

Es una medida cuantitativa que asigna el equipo a cada historia. Los puntos historia miden la dificultad que se intuye que tendrá la historia para ser construida, comparada con el resto de las historias de la pila. Es decir no es una medida absoluta, es una medida de comparación.  Existe una técnica llamada “Planning poker” para medir puntos historia.

6 – Pila de producto

El propietario de producto es el responsable de la pila de producto. La pila de producto es una lista que contiene todas las historias que describen el producto. El propietario de producto prioriza las historias, al principio coloca las que se prevea que aportarán más valor para el negocio. Las historias del principio de la pila deben estar suficientemente detalladas para que el equipo de desarrollo tenga la información necesaria para poder construir el software, el resto de ellas pueden estar definidas más vagamente. Esto se debe a que en SCRUM el cambio es bienvenido, es decir, puede ocurrir que una historia que en principio se identificó como tal, después de varias iteraciones (sprints) se considere que ya no es importante y se elimine. También que aparezcan nuevas historias o cambien historias existentes. Por eso, no es útil que las historias de usuario del final de la pila, que todavía no se van a implementar o quizás no se implementen nunca, estén perfectamente detalladas.

7 – Sprint

Periodo de tiempo previamente fijado durante el cual el equipo desarrolla las funcionalidades y características descritas en las historias de usuario. Los sprints se suceden de forma iterativa en el tiempo, hasta que se haya terminado el producto. Los sprints se acaban cuando acaba el tiempo prefijado, si hay trabajo no terminado se reajustará en subsiguientes sprints. Se recomiendan sprints de 1 a 4 semanas y nunca de más de 6. Es importante que las historias de usuario que se acuerde llevar a cabo en un sprint, no se cambien durante el transcurso del sprint,  el objetivo es no alterar el trabajo del equipo.

8 – Reunión de planificación del sprint

El equipo de desarrollo se reúne con el propietario de producto y trabajan sobre la pila de producto. El equipo analiza las historias de usuario, debatiendo con el propietario de producto sobre su naturaleza. Se seleccionan tantas historias del principio de la pila de producto como el equipo considere que va a poder desarrollar durante el sprint, los puntos historia ayudan a saber cuántas historias seleccionar. Las historias seleccionadas pasan a la pila del sprint y se subdividen en tareas, de tal manera que el equipo desmenuza cada historia en las actividades necesarias para implementarla.

Se prepara el tablero SCRUM del sprint (“Por hacer”, “Haciendo”, “Hecho”) y se colocan las tareas de las historias seleccionadas en la columna “Por hacer”.

9 – Reunión SCRUM diario

Esta reunión se celebra cada día de cada sprint, normalmente al comienzo de la jornada de trabajo. Es una reunión breve, no más de 15 minutos. En esta reunión cada miembro del equipo dice como le fue con las tareas del día anterior y que tareas planifica hacer hoy.

  

10 – Reunión de revisión del sprint

Terminado el sprint el equipo hace una demo del software construido al propietario de producto y a los clientes/usuarios. El objetivo es mostrar el software construido y obtener retroalimentación sobre la perspectiva de clientes/usuarios y el propietario del producto. En caso de que se cumplan las expectativas de todos ellos seguir adelante, en caso de que no hacer los cambios necesarios para cumplirlas. 

11 – Reunión de refinamiento de pila de producto

Se reúne el propietario de producto con el equipo de desarrollo, para revisar las historias que se prevé abordar en el próximo sprint. En base al software construido y a posibles cambios producidos en el transcurso del tiempo, se refinan las historias de usuario: re-priorizar, eliminar, modificar y/o  crear nuevas historias. La idea de refinamiento es doble, por un lado se trata de aportar más detalles sobre las historias del próximo sprint y por otro lado reajustar la priorización de las historias para adaptarse al momento (gestión de los cambios).

En Scrum desde el primer sprint el usuario dispone de software construido.  Esto permite que el desarrollo del producto se realice siguiendo unas especificaciones que se basan en la realidad de un software funcionando en vez de hipótesis sobre lo que debería de hacer o no el producto.

12 – Reunión de retrospectiva

Al final de cada  sprint se celebra una reunión de retrospectiva. La retrospectiva vigila el proceso, no el producto. La retrospectiva, lo que persigue es que el equipo: desarrolladores, propietario de producto y clientes/usuarios, pongan de relieve aquellas cosas que creen que pueden hacer mejor para el próximo sprint. Por ejemplo: los SCRUM diarios se han alargado cada día durante más de 2 horas y el equipo ha perdido mucho tiempo. Aquí una mejora es proponerse mantener el scrum diario en los 15 minutos estipulados para los próximos sprints.