Artefactos de Scrum. Sprint Taskboard

7 de octubre de 2015

Cuando se habla de Scrum una de las primeras imágenes que se nos suele pasar por la cabeza es un tablero con columnas, algunos gráficos y una buena cantidad de Post-Its. Se trata del Sprint Taskboard.

Los tableros de Scrum no son una herramienta oficial del framework sino que provienen del visual management y la metodología Kanban.

Se suelen dividir en varias columnas que representan los estados por los que puede pasar una tarea y en un gráfico Sprint Burndown que refleja, día a día, el trabajo restante.

La parte de las columnas suele representar tres estados fundamentales de las tareas, pendientes, en progreso y finalizadas. En la imagen superior he querido reflejar el panel con el que suelo trabajar el cual incluye varias columnas adicionales. Analicemos el flujo de vida de una tarea.

  • New Request. Esta columna representa una especie de recámara de tareas, es decir, tareas todavía no activadas para ser llevadas a cabo durante el Sprint. Tiene dos utilidades.

    • Puede constituir el Product Backlog del proyecto con todo aquello que el proyecto necesita pero que todavía no ha sido seleccionado para desarrollarse en la iteración actual.

    • Puede almacenar una bolsa de tareas siguientes de modo que, si el equipo terminara todas las tareas del Sprint antes de tiempo podría empezar a trabajar en tareas activables durante el siguiente Sprint.

  • To Do. Contiene las tareas elegidas para ser desarrolladas por el equipo durante la iteración en curso. Cada miembro del Equipo de Desarrollo se irá asignado tareas de esta columna en orden descendente de prioridad, las moverá a la columna In progress y empezará a trabajar en ellas.

  • Action Required. Si al elegir una tarea o mientras se trabaja en ella el desarrollador que la está llevando a cabo encuentra alguna dificultad que no puede ser resuelta por ninguna persona del Equipo Scrum como, por ejemplo, que necesite algún recurso de diseño que todavía no esté disponible, moverá la tarea a esta columna y el Scrum Master se encargará de desbloquear el impedimento que paraliza la tarea.

  • QA Rejected. Las tareas de la columna On Testing pueden llegar a esta columna si no superan la definición de completado o no cumplen con alguno de sus criterios de aceptación. El hecho de que la posición de esta columna sea anterior a In progress y On testing es que representa un paso atrás en el flujo de la tarea, pues debe ser reabierta y corregida antes de poder volver a ser evaluada.

  • In Progress. Las tareas que cada miembro del Equipo está llevando a cabo en un determinado momento ocupan esta posición. Cada desarrollador debería tener, en todo momento, una única tarea en esta columna pues el trabajo en paralelo suele dificultar la concentración y penalizar al resultado de las tareas. Si en algún momento un desarrollador se viera en la situación de no poder avanzar con una tarea debería llevar ésta a la columna Action Required e iniciar otra. En este punto es adecuado señalar que cuando la tarea en Action Required viera cumplida su dependencia el desarrollador no debería parar su tarea actual para retomar la tarea en Action Required sino finalizar la tarea actual y, sólo después, retomar la tarea detenida (las tareas deben iniciarse y completarse sin interrupciones ni ser intercaladas con otras).

  • On Testing. Una vez que el desarrollador ha completado una tarea, la ha probado y ha verificado que cumple los criterios de aceptación especificados para la tarea la mueve a la columna On testing para que el equipo de Quality Assurance la compruebe en un entorno de integración y testing y decida si la tarea está correctamente completada, es decir, cumple todos sus criterios de aceptación y la definición de completado definida para el Sprint.

  • Completed. Si las tareas examinadas por QA en el paso anterior están correctamente completadas el equipo de QA las pasa a esta columna, en caso contrario las pasa a QA rejected.

  • Rejected. Las tareas que, a lo largo del Sprint, se decide no llevar a cabo, por el motivo que sea, pasan a esta columna para que exista constancia que en algún momento se pretendió desarrollarlas. Los motivos por los que pueden llegar a este punto pueden ser de distinta naturaleza, desde que se descubra que la tarea ya no tiene sentido para el producto, que el Product Owner decida no desarrollarla, que ya hubieran sido completadas como parte de otra tarea en otro Sprint, etc.

Además de las columnas por las que puede pasar una tarea tenemos, en la parte derecha, un gráfico y, bajo éste, dos pequeñas columnas.

El gráfico representa el ya mencionado Sprint Burndown Chart, es decir, el gráfico del trabajo restante. Como puede verse en la imagen, en vertical representamos los puntos de historia restantes y en horizontal los días transcurridos.

El primer día la barra de puntos de historia está completa, contiene todas las tareas o historias de usuario del Sprint. A medida que vamos completando tareas y van pasando los días las barras descienden pero vemos que, en el sexto día la barra ha crecido respecto al día anterior, ¿por qué? Podría deberse a que el quinto día se haya detectado que una de las historias de usuario era realmente más compleja de lo que parecía y que haya sido necesario añadir trabajo al Sprint, quizás no como puntos de historia pero sí como horas de dedicación. También podría haberse dado el caso de que el cliente hubiera manifestado algún tipo de imprevisto que el Equipo de Desarrollo, con la supervisión del Product Owner, hubiera decidido comprometerse a incluir dicha funcionalidad en el Sprint sin descartar ninguna otra.

Por último, en las dos pequeñas columnas bajo el gráfico se suele aprovechar para muy distintos fines. En algunos equipos se usa para tener una bolsa de tareas siguientes, a mi no me gusta porque para eso utilizo la columna New request. Otras veces se reflejan en estas columnas las tareas no planificadas, es decir, imprevistos que no estaban inicialmente contemplados en el Sprint. Yo prefiero marcar las tareas no planificadas en otro color o similar para poder identificar en qué punto de su ciclo de vida se encuentran.

En mi caso suelo utilizar una de ellas para contabilizar los impedimentos que van surgiendo y que no se olvide ninguno de cara a la Retrospectiva de Sprint y para que el equipo pueda ver en todo momento el objetivo de Sprint decidido.

Key Points
Pese a no ser un artefacto oficial de Scrum se suele utilizar un tablero con columnas que representan los estados por los que puede pasar una tarea y un gráfico que muestra el trabajo restante.
Los estados fundamentales en que puede estar una tarea son Pendiente, En progreso y Finalizada.
Otros estados pueden ser utilizados para matizar situaciones de tarea más concretas como por ejemplo, New Request, To Do, Action Required, QA Rejected, In progress, On Testing, Completed y Rejected.
El gráfico Sprint Burndown Chart representa el trabajo restante.
En las dos columnas bajo el gráfico se puede tener una bolsa de tareas siguientes, reflejar las tareas no planificadas, contabilizar los impedimentos que van surgiendo de cara a la Retrospectiva de Sprint o recordar el Objetivo del Sprint.

Pineipol
25 de octubre de 2015
Enhorabuena por tu blog, Alejandro!! Me ha encantado toda la serie sobre Scrum. ¿Cuando podremos empezar a ver estas cosas aplicadas en algún proyecto?
Alejandro Barba
25 de octubre de 2015
Hola Pineipol, la próxima serie de posts, que será más corta que ésta, tratará sobre cómo montar un servidor completo en Amazon Web Services, paso previo a empezar con nuestro primer proyecto Agile. Paciencia, ya mismo empezamos!!