En el post Tableros kanban. Parte I: Diseño básico para gestionar flujo de trabajo comenté algunas pautas para diseñar un tablero kanban cuando NO se trabaja con Sprints. Trabajar con Sprints o iteraciones, es decir, aplicar un modelo de proceso iterativo, es una de las prácticas ágiles más protagonistas de Scrum (y también de Extreme Programming) pero puede que no sea conveniente para un determinado contexto de trabajo (lectura recomendada Modelos de proceso para desarrollo ágil). Si el equipo recibe continuamente ítems de trabajo, éstos se van priorizando y abordando según dicha priorización, y en la medida que se terminan se van entregando, en este caso probablemente trabajar con Sprint no es necesario. Es decir, al cliente le podría bastar con que le ofrezcamos un buen ritmo de entrega de ítems terminados. Sin embargo, cuando el cliente quiere establecer un compromiso más estricto respecto de plazos, alcance y/o costo los Sprints ofrecen el mejor mecanismo para el seguimiento continuo de dichas restricciones. Así, por ejemplo, un proyecto de 6 meses podría descomponerse en 8 Sprints de 3 semanas cada uno, teniendo la oportunidad de evaluar el avance del proyecto y gestionar su alcance al final de un Sprint y comienzo del siguiente, en la reunión de revisión del Sprint (Sprint Review Meeting) y la reunión de planificación del Sprint (Sprint Planning Meeting).
Un Sprint contiene un conjunto de ítems que se terminan entre las fechas de inicio y fin del dicho Sprint. Sin embargo, parte del trabajo requerido por los ítems de un Sprint usualmente se realiza antes del inicio del Sprint.
Cuando se usan Sprints las actividades aplicables a un ítem deberían ser básicamente las mismas que se aplican cuando no se usan Sprints. Sin embargo, como veremos más adelante, es de esperar que necesitemos algunas actividades adicionales. A continuación se muestra el kanban del ejemplo que expliqué en la Parte I, respecto de cómo diseñar un kanban SIN usar Sprints.
En la Parte I de este post comenté mi recomendación respecto de incluir explícitamente dos actividades (columnas) en el extremo izquierdo del tablero kanban. En el ejemplo yo las he llamado "Introducir" y "Ordenar". La actividad "Introducir", una vez terminada, nos asegura que el ítem tiene la suficiente información para comenzar a procesarse. Esta información depende del contexto, pero podría incluir, por ejemplo: nombre, fecha de solicitud, quién lo solicita, importancia, riesgo, esfuerzo a priori, etc. Así, sin mayor inconveniente, cualquier posible trabajo aunque todavía no esté completo en sus datos básicos puede ya registrarse y mantenerse en "Introducir". La columna "Ordenar" nos asegura que todo ítem que posteriormente siga su procesamiento ha sido priorizado respecto del resto de trabajo no terminado. Los ítems se etiquetarán con un número de orden que debería seguirse en su procesamiento a través de las actividades del tablero kanban.
Usando el mismo ejemplo de flujo de trabajo (actividades por las que debe pasar cada ítem) veremos a continuación qué necesitamos añadir para poder trabajar con Sprints. Lo primero es reconocer que en cualquier kanban tenemos un grupo de actividades a la izquierda del kanban que se refieren a la preparación de cada ítem, y otra a la derecha que se encarga de ejecutar/implementar cada ítem. En la siguiente figura, y para nuestro ejemplo, se identifican ambos grupos de actividades correspondientes a Preparación y Ejecución de los ítems.
Al trabajar con Sprints lo ideal es que los ítems ya estén preparados antes de introducirlos al Sprint ya que así nos aseguramos que el contenido del Sprint se puede terminar en el plazo asociado al Sprint. En el ejemplo, durante su preparación los ítems se introducen, ordenan, y definen. Si se tienen ítems preparados, al establecer un compromiso de alcance para el próximo Sprint podremos tener mayor certeza que dicho compromiso es razonable en cuanto a esfuerzo involucrado y capacidad del equipo. Hay que destacar que en este caso, dentro de las tareas de la actividad "Definir", estaríamos incluyendo entre otras la estimación del esfuerzo asociado a la realización del ítem, normalmente en Horas Ideales o Puntos (Lectura recomendada: Estimación en un proyecto ágil). Si se considera necesario, podría promoverse la tarea de estimación como una nueva actividad (columna) en el tablero kanban. En nuestro ejemplo, yo no lo haré y asumiré que esa tarea está incluida en la actividad "Definir", es decir, que la tarea de estimación está en la "definición de Done" (las tareas-criterios para dar por finalizada una actividad) de la actividad "Definir" .
Scrum define dos tipos de contenedores de ítems el Product Backlog y el Sprint Backlog. El Product Backlog contiene todos los ítems que aún no se han incluido en un Sprint. El Sprint Backlog son los ítems contenidos en el Sprint, así cada Sprint tendría su propio Sprint Backlog. Para simplificar prefiero simplemente referirme al Product Backlog como "Backlog" y al Sprint Backlog como "Sprint". Así pues, en nuestro ejemplo el conjunto de actividades de preparación deberían idealmente realizarse cuando los ítems están en el Backlog y las de ejecución deberían realizarse cuando ya son incluidos en un Sprint, haciendo coincidir esos contenedores con el trabajo de preparación y ejecución respectivamemente, tal como se muestra a continuación.
En el caso de no trabajar con Sprints no sería tan relevante el concepto de Backlog, pudiendo asumir que el Backlog contiene a todas las columnas del tablero kanban, es decir, el Backlog simplemente sería el conjunto de todo el trabajo no terminado.
Una variante bastante popular en las herramientas que ofrecen soporte para tableros kanban es una en la cual no se reconocen actividades para los ítems durante el Sprint, sino que para cada ítem se define un conjunto de tareas técnicas que deben realizarse para darlo por terminado. Estas tareas pueden estar uno de los tres estados (columnas) elementales: To Do, Doing y Done. Así, al final del Sprint todas las tareas de los ítems del Sprint deberían estar en "Done". La siguiente figura ilustra esta variante de tableto kanban, que afectaría solo a los ítems que están dentro del Sprint.
No recomiendo esta variante porque supone mayor esfuerzo de gestión, debido a que además de gestionar los ítems de trabajo hay que gestionar las tareas asociadas a cada ítem dentro del Sprint. Por otra parte, trabajando con ítems relativamente pequeños (como debería ser lo habitual) no sería necesario hacer mayor descomposición de ellos.
Por otra parte, Scrum sugiere hacer coincidir el término de un Sprint con el comienzo del siguiente. Esto exige una buena disciplina de trabajo que permita llegar al final da cada Sprint con suficiente trabajo preparado para incluirlo en el siguiente Sprint y así poder iniciarlo de inmediato. Para conseguir esto lo recomendable es que a medida que se vaya extinguiendo el trabajo del Sprint actual se vayan dedicando esfuerzo en preparar los ítems candidatos para el siguiente Sprint. En nuestro ejemplo esto significaría tener suficiente trabajo terminado en la actividad "Definir". Sin embargo, los ítems preparados no deberían pasar directemente a la columna "Programar", lo cual debe hacerse en el momento en el cual se inicia su Sprint. Así pues, surge la necesidad de una columna buffer que acumule los ítems preparados, candidatos para un Sprint aún no iniciado. El siguiente diseño de trablero incluye la actividad "Asignar Sprint" (o el nombre que se le quiera dar), desde la cual se cogerían los ítems que entran en el próximo Sprint.
Por último, a continuación comentaré algunas situaciones que suelen crear confusión al abordarlas en un tablero kanban, especialmente cuando se usan Sprints.
- El Sprint ha llegado a su fecha de fin y no se han terminado todos los ítems. Hay varias opciones. La menos recomendable es extender el Sprint pues tal como sugiere Scrum, es importante conseguir una cadencia de trabajo y esto se favorece cuando los Sprints son de la misma duración. Dicho lo anterior, una mejor opción sería que los ítems no terminados podrían volverse al Backlog, a la columna "Asignar Sprint", reevaluando su prioridad (orden). Los ítems ya empezados y que podrían darse por terminados parcialmente (cuando la parte terminada pueda constituir un resultado de valor para el cliente) se terminarían pero se generaría un nuevo ítem con la parte restante del trabajo, el cual se pondría en "Asignar Sprint" reevaluando su prioridad (orden). El caso extremo de ítems ya comenzados, y que no se pueden dar por terminados parcialmente, deberían volverse al Backlog, pero en este caso deberían mantenerse en la columna actual (ya que, por ejemplo, se estaban programando o probando) porque ese es efectivamente su estado. Esta última es una situación excepcional en el tablero kanban pues el ítem está en una columna de Sprint siendo que se ha vuelto al Backlog. Sin embargo, bastaría con marcarlo notoriamente para que no se continue su trabajo hasta que vuelva a incluirse en un Sprint posterior.
- Se han introducido en el Sprint ítems que no están totalmente preparados o tienen defectos en su preparación. De forma intencional se podría introducir un ítem en un Sprint sin haber hecho la preparación, por ejemplo, si se trata de un ítem urgente. En este caso el ítem estará asignado al Sprint actual pero aparecerá en columnas de preparación hasta que no se finalice su preparación (que se haría durante el Sprint).
- Se detectan defectos de preparación en un ítem del Sprint. Cuando un ítem ya está en el Sprint actual y en alguna actividad, por ejemplo, Programar o Probar, se detectan defectos de preparación, por ejemplo, algún defecto en la definición del ítem. Si se trata de un defecto "grande" habría que volver el ítem a la columna correspondiente (en nuestro ejemplo "Definir") con una marca para identificar que se trata de re-trabajo y que posiblemente deba tratarse de forma prioritaria. Una vez resuelto el defecto habría que evaluar si el ítem debería volverse a la actividad desde la cual se volvió atrás o si debería pasarse a una actividad intermedia para realizar otros re-trabajos necesarios. Si el defecto es "pequeño" se podría mantener el ítem en la actividad donde se detectó el defecto y marcarlo para solicitar resolver de forma prioritaria dicho defecto (por ejemplo, se prodría re-Definir pero manteniéndo el ítem en la actividad actual).
- Los ítems del Sprint se han terminado antes de la fecha de fin del Sprint. Siguiendo la recomendación ya indicada respecto de la regularidad de los Sprints lo apropiado sería añadir más ítems al Sprints de forma que se mantenga su fecha de fin.
- Cuando se quiere establecer de antemano el contenido de todos los Sprints hasta el término del proyecto. Hasta ahora, el trablero kanban que hemos visto solo incluye el Sprint actual, el resto de ítems del proyecto estarían en el Backlog. Recomiendo firmemente no caer en la tentación :-) de pre-asignar todos los ítems a Sprints hasta distribuir todo el contenido del proyecto. Cuando se presentan cambios en cuanto a nuevos ítems, cambios en prioridad de ítems, descarte de ítems, etc. es muy molesto tener que re-establecer en cascada el contenido de los Sprints anticipadamente definidos. Pero además es problemático distinguir en un tablero kanban físico qué ítems están asignados a qué Sprints, pues el Backlog se reduciría prácticamente a las primeras columnas del tablero y el resto de columnas que usualmente serían del Backlog serían columnas donde habría ítems de los Sprints futuros. Si el interés es gestionar el alcance del proyecto debería bastar con tener señalados en el Backlog los ítems que se ha acordado que no están incluidos en el proyecto, por ejemplo, en la columna "Ordenar" indicar a partir de qué ítem (en la lista ordenada) ya no se considera dentro del alcance del proyecto.
- Si un ítem de trabajo es una épica (un ítem grande y/o complejo) y ocuparía gran parte de la capacidad del Sprint o incluso no podría terminarse antes del término del Sprint. Mientras el ítem esté lejos de ser incluido en un Sprint (por ejemplo, en más de un mes) no debería preocuparnos mayormente. Si por contrario ya estamos cerca de incluir la épica en un Sprint deberíamos estudiar cómo se abordará. Si la épica puede descomponerse en ítems bastante independientes (desde la perspectiva del cliente) esta sería una buena opción, con lo cual todo o parte de dichos ítems se incluirían en un Sprint, y el resto en otros. Si la épica es difícil de descomponer en ítems independentes pero es factible terminarla dentro de un Sprint, podría mantenerse como un solo ítem a costa de gestionar más colaborativamente su realización dentro del Sprint, por ejemplo, estableciendo que varios programadores o testers deben trabajar en conjunto en el mismo ítem. Sin embargo, mi opción preferida, es darle una "vuelta de tuerca" a la definición de la épica y plantearla como un desarrollo MVP, es decir, desarrollarla incrementalmente. Esto significa establecer un ítem como una primera mínima versión que se incluirá en un Sprint y mantener otro ítem en el Backlog (en la columna "Definir") con el resto del trabajo asociado a la épica. Una vez terminada esa primera versión, establecer otro ítem como una siguiente versión del ítem para el próximo Sprint, y así sucesivamente hasta terminar todo el trabajo asociado a la épica o hasta que la prioridad del ítem restante ya no esté entre lo que debería ser incluido en el siguiente Sprint, con lo cual dicho trabajo restante debería esperar hasta alcanzar mayor prioridad.
- Cuando se quiere utilizar Sprints solo como agrupador de trabajo, es decir, "Sprints flexibles". Esto sucede cuando no existe un compromiso estricto con la parte cliente en cuanto a una fecha de fin de Sprint (o de entrega de versión de un producto), o cuando el contenido del Sprint puede modificarse durante el Sprint. Es decir, tenemos un buffer de tiempo y/o de ítems, pudiendo, sin mayor problema, pasar ítems no terminados al siguiente Sprint cuando ya se quiere dar por terminado el Sprint actual, o extender (o acortar) la duración del Sprint. Obviamente esta situación no ocurre cuando hay un contrato Precio Fijo entre cliente-proveedor :-). Pero en otros casos en los cuales el proveedor ofrece actualizaciones de su producto sin compromiso estricto de fechas ni de contenido con el cliente, estos "Sprints flexibles" suele ser la opción más apropiada. De todas formas, me reafirmo en la recomendación en cuanto a regularidad de los Sprints pues genera confianza al cliente, y puede ser especialmente interesante cuando los Sprints generan nuevas versiones de un producto que ya está en producción.
- Cuando en el Backlog o Sprint hay ítems que siguen diferentes workflows. Una de los mayores limitaciones de un tablero kanban físico es poder gestionar ítems que tienen diferentes workflows, es decir, que las actividades aplicables son diferentes según el tipo de ítem. Cuando un tablero kanban incluye columnas aplicables que no son aplicables a un ítem, al desplazar el ítem éstas columnas deberían saltarse, lo cual puede llegar a ser complicado de manejar manualmente (pueden darse errores en el movimiento de los ítems). Lectura recomendada: Tableros kanban: ¿por qué recomiendo utilizar una herramienta en lugar de un "tablero kanban manual" y qué funcionalidades debería ofrecer?.
Como hemos visto en este post, la práctica del método Kanban que se refiere a la visualización del trabajo no terminado usando tableros kanban, y la práctica de Scrum respecto de realizar un desarrollo iterativo e incremental pueden aplicarse conjuntamente siendo complementarias. Aprovecho, como siempre :-), para insistir en que aplicar agilismo no es necesariamente aplicar al 100% un solo método ágil, sino que es aplicar prácticas ágiles en la mayor cantidad y profundidad posible, independiente del método ágil que provengan (lectura recomendada Carta de prácticas ágiles: Arma tu propio menú ágil).
En nuestro enfoque TUNE-UP Process y su herramienta de apoyo hemos abordado todas las características que he comentado en este post y que son necesarias para dar un buen apoyo para tableros kanban, trabajando con o sin Sprints.
Patricio Letelier
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com
