Agile Story Board

Empecemos por la definición de la wiki, un StoryBoard es una serie grande de viñetas que ordenan la narración de los hechos de una película. Se utiliza como planificación previa a la filmación de escenas y secuencias; en él se determina el tipo de encuadre y el ángulo de visión que se va a utilizar. Sirve cómo guia al director, no obstante este puede desglosar y segmentar su filmación sin seguir estrictamente el orden lógico de la trama.

Esta definición viene del mundo del cine, pero creo que nos sirve perfectamente para ilustrar su valor a la hora de ayudarnos en la gestión de un proyecto. Se trata de visualizar y compartir el grado de avance del proyecto en unos grandes gráficos mostrados en la pared de la habitación del equipo de proyecto.

Tienen una interpretación diferente para UCD y para AD, para UCD se trata de la definición de un flujo de navegación (User Interface Flow Diagrams) pero este post lo dedicaremos al StoryBoard de AD, los cuadros de mando ágiles. Dónde también los podemos conocer cómo Taks Board.

¿Qué tiene un StoryBoard?

Al igual que sucede con la metodología ágil en general, cada maestrillo tiene su librillo, es decir que cada organización y proyecto tienen personalizaciones y adaptaciones ad-hoc, una vez presentemos la estructura estándar compartiré algunas referencias concretas como ejemplos ilustrativos.

En general, suelen compartir lo siguiente:

Columnas básicas 

• Stories. Historias o Casos de Uso a desarrollar. Las historias se dividen en 1 o más tareas (breakdown(1)) que cambian de columna en función del siguiente ciclo de vida
• ToDo. Tareas pendientes de ejecución
• In Progress. Tareas iniciadas, en curso
• Complete. Taras finalizadas

Filas. Una para cada historia

(1) La subdivisión de Entregas/Release, Stories y Tareas se ve muy cláramente en el siguiente esquema visual, propio de la estructuración Kanban, que también analizaremos en el Blog.

Evidentemente podemos complementarlo incluyendo una columna para indicar que están pendientes de verificación, o la estimación de horas, o lo que se más requerido para nuestro equipo. También puede ser interesante reflejar la prioridad y si existe alguna dependencia (aunque finalmente esto se traduce en prioridad / estar o no estar en el camino crítico)

¿Cuándo y cómo usar los StoryBoards?

Suele ser habitual que sean públicos, recordemos el compromiso de comunicación que tenemos, pese a todo, en ocasiones puede ser más interesante disponer de un StoryBoard digital, da privacidad, disponibilidad distribuida (por ejemplo si tenemos miembros que trabajan en otras sedes o remotamente) y por encima de todo trazabilidad y control histórico.

Un problema de tener ambos sistemas es que puede minimizar el impacto o la relevancia que le de el equipo al sistema. Y para que no se hospede una tendencia a delegar a las figuras de Scrum Master y Product Owner la gestión del estado del Sprint. O dedicarse únicamente a su versión digital, desactualizando hasta morir la versión visual.

Otra práctica discutible es obviar el StoryBoard, muchos equipos ágiles trabajan con track tools, no utilizando el StoryBoard, pierden de vista lo siguiente:

• El StoryBoard ayuda a estar focalizado. Es la herramienta perfecta sobre la que realizar los daily meetings.
• El StoryBoard muestra de manera evidente la realidad del proyecto, la velocidad de desarrollo del equipo, y el progreso completo del proyecto (Burndown chart)
• Ayuda (para ello es imprescindible que sean digitales) a equipos remotos, para compartir el trabajo y reducir la complejidad, o la falta de contacto personal en esas situaciones
• En resumen, es el jugador nº8  (Es que yo soy jugador de balonmano ;D )

Crear tu StoryBoard

Cómo os comentaba con anterioridad es vuestra obligación, como en todo en la vida, encontrar la configuración idonea para vuestro equipo, para vuestro proyecto, para el contexto concreto en el que os encontréis. 

Existen equipos a los que les funciona trabajar con historias y sin tareas, o con bugs, las motivaciones son subjetivas y no debatibles, la velocidad te permite demostrar que es lo más conveniente para tu equipo, en caso contrario, después de la siguiente retrospectiva, pensar en soluciones y llevarlas a cabo durante el siguiente Sprint.

Os pongo un ejemplo interesante aquí

Ejemplos

Ejemplos gráficos de los muchos que podéis encontrar en Internet

El segundo de los ejemplos incluye un BurnDown Chart, que explicaremos específicamente en otro artículo.

Me parecen muy interesantes el artículo de Kenji Hiranabe y de manera especial todo el Blog de Xavier Quesada

Saludos,