Ya hemos hablado en un par de ocasiones del sprint backlog.
Por un lado, durante la planificación del sprint, tenemos que confeccionar el sprint backlog, y por otro lado, durante el daily scrum, hay que ir actualizando su contenido.

La teoría la sabemos, pero... ¿cómo confeccionamos y actualizamos en Unkasoft este sprint backlog?

Nosotros nos basamos en la plantilla para sprints de SCRUM que publicó hace tiempo Juan Palacio (con algún retoque nuestro).
Estuvimos evaluando otras plantillas, pero no nos han convencido por ser demasiado complejas (y porque apostamos por los productos nacionales :)

En esencia, la plantilla de sprint que usamos nos hace las funciones de tablón virtual donde vamos dejando tarjetas de las tareas a completar y las vamos moviendo de sitio cuando están terminadas.
Durante el daily scrum, actualizamos cada tarea, apuntando las horas que quedan para completarla, y la propia plantilla nos saca gráficas de esfuerzo (que los ingleses llaman burndown charts).

Basicamente, la plantilla tiene tres secciones:

Configuración:
Damos varios datos del sprint que vamos a realizar, como el número de días que dedicaremos, número de horas de trabajo al día, tipos de tareas a realizar (codificación, reunión, pruebas, documentación, etc.), estados de cada tarea, integrantes del equipo o días festivos que tendremos durante el sprint.

Datos:
Aquí apuntamos las tareas que hemos ido extrayendo durante la planificación del sprint, apuntando la estimación en horas, el tipo de tarea.
Por cada tarea, a la derecha tenemos las horas que faltan para completarse en cada uno de los días del sprint. Así, si no se avanza en una tarea, veremos como sus horas no disminuyen, lo cual es una cosa mala.
Basándonos en ese total de horas y en la velocidad de desarrollo (un factor entre 0 y 1 que hemos añadido), podemos calcular la fecha estimada de cierre, distinta para cada día del sprint, para así ver si vamos a buen ritmo o llevamos retraso.
Otra cosa que hemos añadido es una columna con las horas reales dedicadas a cada tarea, que rellenamos cuando la tarea se termina. Aunque SCRUM no habla nada del control horas estimadas-reales (sólo controla las reales), nosotros lo necesitamos por temas de presupuestos, costes, etc.

Gráficos:
Por último, basándonos en los datos de esfuerzo de cada tarea, podemos sacar el famoso gráfico de esfuerzo (burndown chart) y otros gráficos para ver la evolución de las tareas, cómo fluctúa la fecha de cierre, o la carga de trabajo asignada a cada programador.

Sobre cómo interpretar estos gráficos, hay mucho que hablar. Aquí cuenta mucho la experiencia y la intuición (como en todo gráfico que se precie), aunque os recomiendo que leáis este post sobre los cinco signos de problemas durante una iteración. Nosotros creo que ya los hemos sufrido todos (:
También existen gráficos más complejos para gestionar de forma correcta las tareas introducidas a mitad del sprint.

Bien, esto poco a poco va llegando a su fin.
El próximo día hablaremos un poco sobre cómo combinamos eXtreme Programming con SCRUM.

Etiquetas: agile, SCRUM