Scrum es la adaptación de las metodologías ágiles más conocidas, y como tal es un framework que persigue los 12 principios del Manifiesto Ágil.

Siguiendo con estos principios, Scrum asume la entrega continuada del producto en verisiones estables periódicamente. Esto significa que el cliente verá como su producto incrementa su valor con cada nueva versión. Es un proceso por tanto iterativo, que se repite continuamente mientras el cliente necesite añadir nuevas funcionalidades al producto.

Para organizar el trabajo y no solo mejorar el producto, sino su proceso de elaboración, Scrum define un ciclo con una serie de hitos, fases y artefactos.

Los hitos son eventos, generalemente reuniones, que se producen a lo largo del ciclo de Scrum. Las fases son periodos de tiempo en los cuales el equipo Scrum se organiza con un fin especifico. Ambos están relacionados entre si mediante los artefactos de Scrum que son objetos creados para guiar el trabajo. Vamos a ver y relacionar todos ellos a través de la siguiente imagen que resume bastante adecuadamente todo el proceso:

El Product Backlog

El Product Backlog es el elemento central de Scrum. Es la pila de tareas que se deberán desarrollar para la consecucion del proyecto. Este artefacto está únicamente manejado por el Product Owner, que añadirá, eliminará y modificará tareas. Estas tareas deberán estar correctamente explicadas y con objetivos de terminación claros para que el equipo de desarrollo las evalúe y añada las que consideren que pueden desarrollarse en un sprint al propio Backlog del sprint. El Product Backlog contiene las tareas ordenadas en funcion de la prioridad que el Product Owner considere, pero eso no garantiza que vayan a ser implementadas en ese orden, sino que depende del equipo de desarrollo.

Usualmente las tareas del Product Backlog comienzan siendo más abstractas y se concretan a medida que avanza el tiempo, pues el cliente va teniendo más claro qué es lo que quiere y el Product Owner podrá detallar mejor los requerimientos.

Este artefacto es icónico de Scrum. Se suele representar y se recomienda que sea así, mediante una serie de columnas en las cuales se pegan papeles adhesivos con un código de colores en funcion de otros parámetros que se quieran representar: urgencia, complejidad, tipo de tarea, etc. Muchas veces se suele usar una pizarra, pero sirve cualquier superficie que sea visible y accesible para los miembros de Scrum. A diferencia del Backlog del sprint, no contiene diferentes columnas, ya que el estado de las tareas no varía hasta que se introduce en un sprint.

Refinamiento del Backlog

El objetivo de esta reunión es la de refinar las tareas del Backlog para su mejor comprensión durante el sprint. En este refinamiento el equipo de desarrollo se hace una idea de los recursos y el tiempo que le va a llevar completar cada una de ellas, estableciendo dependencias y recursos necesarios. Posteriormente pueden existir errores de estimación, pero la idea es que en esta fase se consiga acercar lo más posible la estimación a los recursos y tiempo reales del sprint, así como aclarar aquellas tareas del Backlog que no estén lo suficientemente claras.

La planificación del Sprint

La planificación del sprint es una reunion del Equipo Scrum (Product Owner, equipo de desarrollo y Scrum Master) en la que se van a elegir las tareas que van a formar parte del sprint. Estas tareas deben estar en el Backlog Product y pasarán a formar parte del Backlog del sprint. El Produt Owner se encarga de que todo el equipo entienda cual es la finalidad de cada tarea y en conjunto dirimen sobre la complejidad y el tiempo de desarrollo de cada una de ellas para llegar al estado de terminación de cada tarea. Aunque el Product Owner haya ordenado las tareas en el Product Backlog en función de prioridad, corresponde al equipo de desarrollo el elegir aquellas que formarán parte del siguiente Sprint.

El sprint Backlog

El Backlog del sprint es el icono por excelencia de Scrum. Consiste en una tabla con una serie de columnas por las cuales van pasando las tareas en función de su estado actual. Estas tareas son las escogidas durante la planificación del sprint. A medida que van cambiando de estado, van llegando a la ultima columna, que debe ser la de «terminado».

El Backlog del sprint tiene también una característica visible en las tareas y es que durante la planificación del sprint, a cada tarea incluída se le asignó un peso o un numero de horas para completarla. Esto nos sirve para manejar mejor los tiempos del sprint y tambien para hacer después una revisión y retrospectiva de cómo fue la estimación y conocer mejor al equipo, como veremos en sus respectivos hitos.

Es importante que cada tarea del sprint le corresponda a una y solo a una persona. Esto no quiere decir que no pueda pedir ayuda a sus compañeros pero

Existen muchas formas de organizar el Backlog del sprint, por ejemplo usando múltiples filas en función de la temática de la tarea, pero en cualquier caso, el común denominador es el flujo de las mismas. Al igual que el Product Backlog, el Backlog del sprint debe estar en un lugar accesible y visible para que los miembros del equipo sean capaces de ver el estado actual del sprint y poder manipular el estado de las tareas.

tablero scrum

Sprint

El sprint es la parte central del ciclo de desarrollo. Aquí el equipo de desarrollo se afana en introducir e implementar todas las tareas definidas enm el Backlog del sprint. La duracion es variable, en funcion del numero de tareas pero se recomienda que se mantenga constante en todo el proyecto y comprenda entre 2 y 4 semanas. Durante este periodo de tiempo el equipo trabaja a contrareloj y el Scrum Master procura evitar los impedimentos que puedan afectar al ritmo del trabajo. Es obvio que en esta fase el equipo puede estar sometido a estrés. No es deseable. El sprint debe ser exigente, pero no estresante para el equipo de desarrollo. La manifestacion de sintomas de estres derivan en frustración y falta de motivacion, por lo que para Scrum es de vital importancia atajarlos rápidamente. Por desgracia, el sprint no se puede detener y aunque es cierto que el estrés no es algo que pueda aparecer el el plazo de tiempo que sucede un sprint, fallos de estimación continuados que lleven al limite al equipo de desarrollo pueden ser fatales para el desempeño del equipo.

Durante el sprint el equipo de desarrollo tiene que ser autosuficiente y autorganizarse de manera que consiga llevar a cabo todas las tareas sin ayuda externa.

El Scrum diario

El Scrum diario es el ritual más definitorio de Scrum. Consiste en un a pequeña reunion a primera hora de la jornada laboral con una duracion no superior a los 15 minutos en los cuales los miembros del equipo responden a tres preguntas: qué hicieron ayer, qué harán hoy y qué dificultades se están encontrando.

El Scrum diario sirve para que todo el equipo conozca el estado actual del proyecto y des sprint, pudiendo identificar qué cosas van funcionando y cuáles no. El Scrum Master deberá tomar nota de las intervenciones de la reunión y facilitar la labor del equipo de desarrolo en aquellas cuestiones que no estén funcionando correctamente.

Es recomendable llevar esta reunión preparada de antemano para no excederse de los 15 minutos estipulados.

La revisión del sprint

La revisión del sprint es el siguiente hito tras el sprint. En esta reunión el Product Owner repasa las tareas definidas en el Backlog del Sprint y pide al equipo de desarrollo que se las muestre. El encargado de cada tarea da un paso al frente y demuestra que la tarea efectivamente se ha hecho y cómo. De esta manera todo el equipo llega a tener un conociemiento profundo de la tarea.

El cliente o Stakeholders pueden estar presentes en la demostración de la nueva version del producto.

La retrospectiva del sprint

Durante la retrospectiva del sprint se hace una evaluacion de todo el ciclo. El Scrum Master debe llevar la moderación de la reunión y los miembros del equipo deben comentar cuales han sido sus impresiones del ciclo, desde la planificacion hasta la revision del sprint.

El objetivo de esta reunión es la de generar un espacio seguro para la crítica constructiva entre los miembros del equipo Scrum. Es una reunión para sacar a la luz los problemas y darles una solución grupal. Todos los miembros deben asistir con la mente abierta y asumiendo sus errores, pero sin autocomplacencia, sino buscando mejorar el siguiente ciclo de Scrum mediante su superacion.

La retrospectiva es el punto de inflexion y es lo que marca que el equipo avance realmente en todos los aspectos para lo que se ha implantado Scrum en la empresa: independencia, autogestión y responsabilidad.

El Scrum Máster además deberá tomar nota de todos esos problemas que van surgiendo en cada retrospectiva para proponer soluciones a aquellas cuestiones que se repitan ciclo tras ciclo y abordarlos en las retrospectivas.

Y vuelta a empezar…

Scrum es un framework de mejora continua, no solo del producto sino del equipo. Una vez liberada la nueva versión, se debe volver a la fase de refinamiento del Backlog. Para este momento el Product Owner ya habrá colocado en el tablero del Backlog Product nuevas funcionalidades a ser implementadas y el equipo de desarrollo tendrá que volvera revisarlas, estimar el esfuerzo necesario y planificar el siguiente sprint.