Kanban es un método de gestión del trabajo a realizar en los distintos proyectos con los que nos encontramos, el cual sigue una estructura pull, con la que serializamos las tareas a realizar, las cuales seguirán un camino, desde su aparición, hasta su consecución.

Con ello lo que se pretende es optimizar el flujo de trabajo y mantener un ritmo estable y eficiente.

Como siempre cuando aparece el término eficiente, sabemos que va directamente ligado a las tres palabras claves … medir, medir y medir. Para saber, hay que medir.

Durante el ciclo de vida de nuestras tarjetas, estas pasarán por distintos estados, columna tras columna, siguiendo un camino, que deberemos estudiar si queremos mejorar nuestra eficiencia en el desarrollo del proyecto.

Dependiendo de qué queramos analizar, la estructura de nuestro equipo, o la naturaleza de nuestro proyecto, nos podemos encontrar distintos flujos de trabajo. Personalmente suelo usar 2 modelos base sobre los que trabajar:

• En función del estado de la tarea. Partiendo del flujo básico: To Do –> In Progress –> Done, al que podemos definir estados (columnas) adicionales como To Validate u otros que consideremos oportunos según cada proyecto.
• En función del departamento. Si las tareas a desarrollar van a requerir pasar por distintos departamentos o personas, nos puede interesar definir columnas por cada departamento y que la tarjeta evolucione por ellos hasta llegar a un definitivo Done. Un ejemplo web sería: To Do –> Design –> FrontEnd –> BackEnd –> Testing –> Done

Una vez tenemos definido nuestro flujo de trabajo, es hora de empezar a trabajar y medir.

Según nuestro día a día, la evolución del proyecto, del equipo, o las mediciones que consigamos, harán que nuestro flujo de trabajo pueda cambiar, teniendo que añadir/eliminar columnas según vayamos viendo.

Vamos a ver algunas de las métricas que nos ofrece Kanban para mejorar nuestros flujos de trabajo, y por consiguiente la eficiencia de nuestro proyecto.

Lead Time

El Lead Time nos permite saber cuánto tardamos en responder a una necesidad del usuario. Mide el tiempo que transcurre desde que una necesidad es identificada (entra en nuestro flujo de trabajo) hasta que se entrega (sale del flujo de trabajo). Es decir, mide el ciclo de vida de una actividad.

En términos más concretos, el Lead Time de un PBI (Product Backlog Item) mide el tiempo que ha transcurrido desde que éste se creó en el Product Backlog hasta que se puso en DONE, pasando por todos los estados intermedios que tenga nuestro flujo de trabajo particular: priorización, desarrollo, pruebas de calidad, etc.

Como vemos, el Lead Time va más allá del tiempo que tardo en desarrollar una tarea (este tiempo lo mide el Cycle Time, que veremos a continuación). Desde el punto de vista del usuario, es el tiempo que él tiene que esperar desde que me pide algo hasta que yo se lo entrego.

Cycle Time

El Cycle Time es similar al Lead Time, pero comienza a medir desde que la tarea empieza a desarrollarse. En otras palabras, el Cycle Time mide el tiempo transcurrido desde que un PBI entra en IN PROGRESS hasta que se pone en DONE.

¿En qué se diferencia del Lead Time? El Cycle Time no nos da información sobre cuánto hago esperar a mi usuario, sino sobre cuán eficiente soy, como Development Team, en realizar el desarrollo de una tarea y entregarla.

Un ejemplo: considerando el tiempo que los elementos pasan en el Backlog, un PBI podría tener un Lead Time muy alto y un Cycle Time muy corto: la diferencia es, casi en su totalidad, el tiempo que he tardado como Product Owner en priorizar ese PBI.

WIP

El WIP, o Work In Progress, no mide un período de tiempo transcurrido, sino que es un indicador que nos permite saber cuántos elementos tengo siendo desarrollados en un instante concreto. Es decir, es la cantidad de PBIs que se encuentran en IN PROGRESS en un momento dado.

Pero ¿a qué nos referimos con IN PROGRESS? Parece evidente, pero no siempre lo es. Los tres estados naturales de cualquier acción son “Por hacer”, “Haciéndose” y “Hecho”. No hay ninguno más, es lógicamente imposible. Sin embargo, en nuestro flujo de trabajo seguramente nos encontremos la necesidad de desglosar estos estados en actividades o fases más pequeñas para visualizar y gestionar más fácilmente mis procesos.

Cuando planteemos estas nuevas fases, veremos que encajan en uno de los tres estados naturales: si quiero incluir una fase que sea QA para saber qué tareas tengo que testear, veré que es un estado de progreso, porque ni está por empezarse ni se ha terminado aún. Por otra parte, tener dos fases en TO DO como las de la imagen superior nos permite diferenciar entre los PBIs que están en el Backlog y los que están priorizados y listos para su desarrollo. A esto es a lo que nos referíamos hace unos párrafos cuando hablábamos de la optimización de nuestro flujo de trabajo.

Volviendo al WIP: si tengo varias fases de progreso, ¿qué tengo que medir, entonces? Recordando el objetivo de esta métrica, que es saber la cantidad de PBIs que tengo en progreso, debemos medir el estado IN PROGRESS total. Sin embargo, medir cada una de las fases internas nos dará visibilidad sobre su estado de salud. ¿Pocas cosas en “Development” y muchas en “QA”? Suele ocurrir. Mide el WIP de cada una de ellas y tendrás información para mejorar tus procesos.

Throughput

Si conoces la velocidad de Scrum, esta métrica te será familiar. El Throughput mide la cantidad de elementos de trabajo que termino en un período de tiempo. A diferencia de su hermana, el Throughput no mide Story Points o Historias de Usuario, sino el total de PBIs que entrego en un período de tiempo, independientemente de su naturaleza.

¿Y qué período de tiempo es ese? Trabajando en Kanban, que no tiene iteraciones, será el que decidamos como equipo. Podemos comenzar midiendo lo que entrego en una semana o en un mes y mantener esa unidad de medida estable, pero adaptarla en el futuro si siento la necesidad de aumentar o reducir el período de tiempo que mido.