Metodologías

Cómo funcionan los tableros Scrum y por qué son útiles

En primer lugar, ¿un tablero Scrum y un tablero Kanban son lo mismo? En realidad, sí, porque la herramienta en todo caso (tanto si estamos en un ambiente Scrum como si no) es el tablero Kanban: un tablero de trabajo que el equipo utiliza para gestionar su trabajo. Con “su trabajo” no nos referimos simplemente a las tareas, sino también las dependencias entre ellas, dependencias externas, captura de métricas relevantes, etc.

Le llamamos “tablero Scrum” cuando este kanban se emplea como tablero para la ejecución de una iteración del proyecto Scrum: las tareas que arrancan en la columna “ToDo” del tablero deben ser aquellas tales que, si se completan antes de la finalización de la iteración, permitirán que se entreguen los requisitos que componen el siguiente producto mínimo viable (la siguiente versión o entrega del producto).

El tablero Scrum funciona como un radiador de información que las personas del equipo utilizan de manera constante: para ver por dónde va el trabajo, para asignarse nuevas tareas, para señalar qué trabajo han terminado, para señalar si tienen algún problema… en definitiva es el panel en el que reflejan el estado del trabajo en cada momento del tiempo.

Tipos de tableros Scrum

Podemos señalar algunos tipos de tableros diferentes:

Tablero Kanban

Se utiliza para ejecutar iteraciones de Scrum, o no: por ejemplo, en la gestión de un servicio que se dedica a la resolución de incidencias; no existen “iteraciones” de tiempo fijo predefinidas, sino que se trata de un trabajo continuo en el tiempo; se utiliza el tablero para trazar y conocer el estado de avance del trabajo de resolución de incidencias.

Tablero Scrum

Es un tablero cuyo contenido es el conjunto de trabajo que se debe llevar a cabo en una sola iteración: cuando comienza la iteración, cargamos en el ToDo las tareas para esta iteración, que se irán moviendo de izquierda a derecha hasta su finalización.

Al final del sprint, “barremos” todo el tablero, es decir lo dejamos completamente vacía, y durante la planificación de la iteración siguiente, volvemos a colocar en el ToDo las nuevas tareas correspondientes a la nueva iteración, y así sucesivamente.

Tablero personalizado

Además de las dos posibilidades anteriores, podemos configurar o ajustar el tablero a nuestro gusto: por ejemplo, para que comprenda iteraciones de un día, de una semana, o de un mes. O para que sólo incluya trabajo de evolutivo o también el relativo a la resolución de incidencias y se muestre de una forma visual clara.

Características de un buen tablero Scrum

Es posible que el diseño del Kanban sea la práctica ágil más difícil de llevar a cabo, puesto que el diseño del tablero debería transmitir hasta 12 datos diferentes, o dicho de otra manera, debería ser capaz de responder, en sólo 2 dimensiones, a nada menos que 12 preguntas de forma simultánea, que vamos a ver una a una.

Si un tablero es capaz de transmitir todo esto, será mucho más sencillo “llevar el proyecto de la mano”, y que no sea el proyecto el que nos lleve a nosotros. Recordemos que el tablero kanban es la herramienta de comunicación más poderosa que utiliza el equipo de proyecto en su día a día.
Vamos a plantearnos todos los puntos siguientes desde el punto de vista de “¿esto es relevante tenerlo claro y controlado para llevar a cabo el trabajo en un proyecto?”

1. Estado: es la dimensión más sencilla, y se resuelve incluyendo una columna en el tablero por cada uno de los estados del diagrama de flujo que representa la definición de “hecho”. Es por ello que los tableros cuya estructura es “to do – doing – done” no ayudan en nada: es obvio que cualquier cosa se va a hacer, se está haciendo o estará hecha. Lo interesante precisamente es poder manejar y visualizar todos los estados intermedios durante su construcción o desarrollo, hasta la finalización.

2. Estado parcial: aunque coloquemos una columna para cada estado o paso intermedio de un diagrama de flujo que representa la definición de “hecho”, tenemos un problema con esa columna: si una tarea está en el estado de “análisis”, por ejemplo, ¿significa que alguien la está analizando, o que está analizada y puede pasar al estado siguiente? La solución es subdividir cada columna en dos partes precisamente: en una parte se sitúan las tareas que están “vivas” en ese estado, es decir se están analizando, en este ejemplo. Y en la segunda subcolumna, las que dicho estado está superado, pero aún no se ha comenzado con el siguiente; esta segunda subcolumna es el “pool” de trabajo de las personas que quieren continuar el flujo de dichas tareas.

3. Quién hace qué. Es decir, qué persona está ejecutando una determinada tarea en un momento dado. Tengamos en cuenta que una tarea puede ir cambiando de manos conforme avanza por el tablero. Una propuesta puede ser utilizar el color de la tarjeta para determinar quién la está llevando a cabo en un momento determinado. Muchas aplicaciones de software colocan la fotografía o un gráfico distintivo. De esta manera, es muy fácil saber cuánto trabajo tiene asignada cada persona, si tiene demasiadas tareas vivas al mismo tiempo, o si por el contrario no tiene ningún trabajo asignado.

4. De qué requisito es cada tarea: una propuesta es organizar el tablero por “carriles” horizontales: todas las tareas de un requisito se mueven a la misma altura del tablero. De esta manera, en un solo vistazo es fácil interpretar qué requisito está más retrasado o avanzado, y nos ayuda a tomar decisiones y a “ver venir” qué requisitos vamos a finalizar a tiempo dentro de la iteración.

5. Dependencias entre requisitos: a menudo no podemos comenzar un requisito hasta que otro está finalizado. Una alternativa muy sencilla es colocar los requisitos según su orden natural de implementación, es decir, en la parte superior los que deben hacerse en primer lugar.

6. Dependencias entre tareas: las tareas también pueden tener dependencias, aunque pertenezcan al mismo requisito, es decir primero hay que resolver o ejecutar la tarea “A” para poder ejecutar la “B”. Una solución “natural” a esto es, igual que con los requisitos, colocar las tareas en el To Do según su orden natural de ejecución. Así, se irán “consumiendo” tomando en primer lugar aquéllas de las que dependen las tareas siguientes.

7. Errores o retrasos: supongamos que una persona ejecutando una tarea se bloquea, se “atasca”, o carece de algún conocimiento, o no es capaz de sacar la tarea adelante… esto es importante visualizarlo lo antes posible para que un compañero pueda ayudarle y hacer avanzar el trabajo. Una solución buena puede ser tener una sección de “error” en el tablero, o mejor aún si es un carril completo que cruce todas las columnas, así se podría dejar la tarea en su estado, pero en modo error, lo cual puede facilitar mucho que una persona bien conocedora de ese estado de trabajo colabore para solucionar el problema.

8. Dependencias con terceros: supongamos que una persona no puede hacer evolucionar una tarea porque depende de otro departamento, empresa o grupo de trabajo… pues bien, esto es necesario visualizarlo cuanto antes para poder “desatascar” dicha dependencia y que se resuelva lo antes posible para no retrasar el trabajo más de lo necesario. Una buena solución, y suponiendo que como hemos dicho antes utilicemos el color para señalar a la persona que debe hacer la tarea, es utilizar también un color para este caso. ¿Cuál? Puede ser cualquier color, pero… será el color del facilitador. Es decir, el facilitador, que es un miembro más del equipo, tiene su color en el tablero. Si las dependencias se le asignan a esta persona, es su trabajo facilitar, comunicar y resolver esas dependencias lo antes posible.

9. Tiempo estimado para la tarea: está claro que debemos reflejar cuánto creemos que vamos a tardar en resolver la tarea (si no, no sabríamos cuánta capacidad de trabajo necesitamos en el periodo de trabajo que represente el tablero). La solución más natural es señalar este número en la misma tarjeta de la tarea, por ejemplo, en su columna inferior izquierda.

10. Tiempo incurrido en la tarea: para poder comparar el estimado con el tiempo total real invertido en ejecutar la tarea (a esto llamamos incurrido), este número debe estar registrado. Cada vez que una tarea cambie de estado (de columna), se actualiza dicho número añadiendo el tiempo invertido en hacerla pasar por ese estado. La solución más natural es reflejarlo en la tarjeta de la tarea, por ejemplo, en su esquina inferior derecha. Este número es una lección aprendida muy útil para aprender a estimar mejor en sucesivas iteraciones de trabajo.

11. Múltiples proyectos: ¿se puede utilizar un único panel para muchos proyectos? La respuesta es sí, siempre y cuando se puedan determinar las mismas columnas para todos ellos. Si eso se consigue, ¿por qué no colocar “un requisito 1 del proyecto 1”, y un “requisito 1 del proyecto 2” en el mismo panel? La idea es poder tener en un solo vistazo y herramienta el trabajo de una iteración, por ejemplo, semanal, que involucre personas en distintos proyectos; esto es muy útil en una start up o un departamento concreto… que llevan distintos contratos, proyectos o iniciativas a la vez, pero el número de personas es reducido y cada una de ellas está asignada a tiempo parcial en cada proyecto.

12. Incidencias: si además de trabajo “constructivo” o de desarrollo, surgen incidencias que solucionar, ¿por qué no incluir una tarea para la resolución de una incidencia sobrevenida? Por su propia naturaleza, las incidencias no se pueden planificar, es decir no podemos predefinir cuántas tarjetas poner en el To Do para resolución de incidencias (si pudiéramos, no se llamarían “incidencias”). Una buena solución es incluir un requisito adicional, que no tiene puntos, pero sí tiene una reserva de horas (la que se considere adecuada); cada vez que surge una incidencia, se crea una nueva tarea dentro de este requisito, con la estimación de horas prevista para su resolución. Si la reserva de horas era de 100 y la estimación de la tarea es de 8, una vez creada la tarea restarán 92 de “buffer” para resolución de incidencias.

Los mejores tableros Scrum del mercado

• Tablero Trello

  El más sencillo posible… y podemos afirmar que demasiado sencillo, porque no permite representar con claridad muchas de las dimensiones que acabamos de citar. Resultará demasiado limitado para proyectos de tamaño medio, es más bien una representación visual de un conjunto de tarjetas, que un “panel de uso profesional” para proyectos reales.

• Tablero Jira

  Sin duda una de las herramientas más utilizadas del mercado, con características potentes: es muy configurable, genera métricas con mucha facilidad, con cuadros de mando muy claros… pero como contrapartida te exige cierta curva de aprendizaje para sacarle el máximo partido.

  Puedes llevar desde pequeños proyectos de 3 personas, hasta grandes proyectos con escalado tipo Scrum de Scrums, evolutivos e incidencias (es decir, no sólo proyectos basados en entregas, pudiendo reflejar ambas cosas a la vez), configuración de visualizaciones analíticas para diferentes perfiles, etc…

  Es la más utilizada porque puedes tener desde el tablero más sencillo de un pequeño proyecto, hasta proyectos con cientos de personas, grandes presupuestos, roadmaps en paralelo, etc.

• Tablero Asana

  No tan sencillo como Trello, pero no tan potente como Jira… la ventaja es que se aprende con mucha velocidad (puedes diseñar un tablero en 10 minutos), pero a cambio la visualización no es tan rica o detallada como puedes hacer en Jira, y está más orientado a la gestión de proyectos basados en entregas.

• Tablero Monday.com

  La filosofía de este tablero se orienta al uso de Grupos, Columnas, Elementos y Subelementos: es buena idea cuando tienes objetivos u entregas que cumplir, cada uno con su presupuesto, divididos en secciones de trabajo. No tiene una filosofía tan agile como Asana o Jira, pero sí te muestra directamente el seguimiento de cada elemento del proyecto o contrato (que se mostrará en porcentaje).

• Tablero Clickup

  La característica más importante de este tablero sería su potente propuesta para visualizar datos del proyecto, la distribución de tareas, tipos de tareas, cálculos de proyecciones de variables… y no sólo para un proyecto, sino que puedes escalar el concepto a un gran contrato, un departamento o hasta una empresa completa. Otro punto a favor es la cantidad de guías y ejemplos para que aprendas cómo ponerla en marcha. Podemos decir que está más cerca del “business management” que del simple “project management”.

Recordemos que ninguna herramienta te dice cómo gestionar un equipo ni gestionar un proyecto, sino que debemos utilizarlas para ayudarnos a visualizar el trabajo que, como gestores y como equipo, debemos saber organizar y gestionar independientemente de la herramienta elegida (que cambiará a lo largo del tiempo conforme se refuerzan o especializan nuestras habilidades de gestión).

Consejos para un tablero Scrum

Además de incluir estas dimensiones de trabajo, todo tablero debería cumplir las siguientes reglas:

• Facilidad de uso y personalización
• Accesibilidad para todos los miembros del equipo
• Visualización clara del progreso del proyecto
• Compatibilidad con herramientas de gestión de proyectos

Y para cumplir estos requisitos, tenemos disponibles herramientas de software como Trello, Jira, Asana, Monday o Clickup, que analizaremos en profundidad en artículos siguientes.

Conclusiones

La gran ventaja de diseñar y utilizar un tablero que sea capaz de transmitir toda esta información es que un equipo de trabajo puede organizarse y gestionar el flujo de trabajo de forma autónoma, sin la necesidad de que un “jefe de proyecto” asigne el trabajo. Es por ello que en entorno ágiles hablamos mucho más de “facilitadores”, que de “jefes de proyecto”.

El tablero Scrum debería considerarse como la herramienta central de la ejecución de todo el trabajo por parte de un equipo de personas.

Finalmente, ¡os invito a que comencéis el Plan Profesional de OpenWebinars! De esta forma podréis realizar todas las formaciones relacionadas con este artículo, disfrutando de un trial de 15 días gratis.