Agile: ¿Que es refinar el Backlog?

El backlog es el listado de tareas o actividades pendientes en un proyecto. Toda actividad en espera de ser tomada y lista para ser trabajada por un miembro del equipo se pone aquí. El backlog puede ser un listado en una hoja de papel, una hoja de electrónica de calculo, un tablero con notas adhesivas o escritos en el pizarron. El medio en el que lo plasmes importa poco. Lo que debes saber es que el backlog es mas que solo un listado, el backlog debe reflejar las prioridades y las actividades del proyecto. Este es un ente vivo del proyecto y requiere de mantenimiento periódico que a continuación te explico:

Examinar todas las tareas del backlog en cada sprint.

En un proceso ágil el valor y la prioridad de las tareas pueden variar con cada iteración, es importante que las tareas se acomoden de acuerdo a su prioridad y el valor que aportan. Las tareas que mas valor aportan deben ir al principio de la lista. No se vale colocar los items al fondo del backlog conforme van apareciendo. Supongamos que estas en el cuarto sprint, surgieron 3 bugs y el equipo se comprometió a solucionarlos en el quinto sprint, las tareas están listas para ser tomadas, en lugar de ponerlas al fondo vas a ponerlas en la parte mas alta del listado para que los miembros del equipo identifiquen que tarea deberían de tomar antes que otra. Obvio, existían items antes,  ahora fueron desplazados. El backlog refleja las preocupaciones y el flujo de trabajo del equipo.

Determinar que las tareas estén listas para ser tomadas.

Toda tarea que este en el carril del backlog debe estar lista para ser tomada por cualquiera. En caso de que no existan los insumos necesarios o existan dependencias que deben de ser resueltas, entonces  la tarea debe ser colocada en otro lugar, por lo general un carril anterior al del backlog para indicar que la actividad existe, pero no esta lista para trabajar en ella. Por ejemplo: el cliente quiere que se agreguen elementos corporativos al diseño del sitio, los archivos necesarios no han sido proporcionados. En el momento que los insumos sean proporcionados deberían incorporarse a la solución ya que el cliente quiere que esto sea visible en las siguientes presentaciones de los sprints. La actividad en cuestión no esta lista, ya que sin los insumos no se puede comenzar. El tratamiento que le des puede variar según la metodología que uses.

Si estas en Kanban puedes mover la actividad a un carril de bloqueados, luego que recibas los insumos pasarlo al backlog para que eventualmente llegue a “en progreso”. En Kanban no hay problemas con actividades que surgen al momento.

Si usas Scrum, esto seria un poco mas complejo. Si la actividad fue prometida en este sprint, debería estar fuera del backlog, en caso de que el cliente envié los insumos en un tiempo razonable y exista el tiempo es posible que la tarea se vaya en este sprint, con el riesgo de que se decida no incluir la actividad en el ultimo momento y perder unos puntos de items entregados. Podrías jugar a la segura no incluir esta tarea en este sprint y esperar hasta tener los insumos en la mano para incluirla en tu sprint planning.

Determinar si las tareas son del tamaño adecuado.

Es posible que una tarea sea mal dimensionada, ya sea que requiere de mas tiempo o incluso que no estés hablando de una tarea grande sino de varias tareas medianas o chicas.  El esfuerzo y el valor de una actividad son estimados a través de medidas subjetivas, conforme avanzas en el proyecto el conocimiento que vas adquiriendo te puede servir para re calcular con mas exactitud el esfuerzo necesario para una tarea. Es un ejercicio muy sano hacer re calculo del tamaño y del esfuerzo en una actividad ne cada iteración. Si una tarea requiere de menos esfuerzo del que se declaro entonces vas a tener desperdicio por handoffs, en cambio si el esfuerzo mencionado es muy poco comparado con lo que te tardaste en realidad vas a tener un sprint donde entregues menos items de los que prometiste. Las tareas no están escritas en piedra y deben de cambiar siempre que sea necesario.

Revisar la “definición de hecho” de las tareas.

Toda tarea debe indicar cuales son los criterios de aceptación y bajo que condiciones esta se considera como entregada. ¿Se considera entregada si el desarrollador hace commit en el repositorio?, ¿se considera entregada cuando se publica en producción?, ¿se considera entregada hasta que el cliente de el visto bueno del trabajo?. Cada tarea debe de especificar que mecanismo se usara para validarse. Por ejemplo: Se reporto un bug relacionado con la limpieza de los datos. Cuando se reciben datos inválidos en el campo total de un componente, este arroja una excepción determinada. Se debe crear un código de error especifico para este caso junto con las pruebas unitarias que validen que el código de error sea retornado en el momento que ocurre este estado en el sistema. Debido a que el componente no tiene interacciones con el usuario no es necesario validación por una persona. En el ejemplo anterior basta con revisar el repositorio, verificar que se hayan codificado las pruebas y esperar a que termine el build para darlo por terminado. Esta definición de hecho fue un acuerdo entre el equipo y algún involucrado del producto. ¿Que hubiera sucedido si no existiese una definición de hecho?, bueno, es posible que se esperara algún tipo de prueba manual y al no verla presente el cliente se negara a darla por buena hasta que se presente algún tipo de evidencia que es difícil de mostrar. Una actividad se finalizo, pero los involucrados no creen que se haya finalizado, tenemos problemas de comunicación.

Eliminar items del backlog.

Algunos items del backlog pueden tener sentido en ciertas fases del proyecto y carecer de este en otras. Esto sucede seguido con características adicionales o “nice to have“. Al principio se ven como items que van a aportar muchísimo valor, luego de unas iteraciones estos items son pospuestos o dejados de lado se quedan como zombis en tu backlog, no se han tomado en muchos sprints ni se tomaran en los siguientes, se conservan por miedo mas que por pragmatismo. Tener items en el backlog sin el compromiso de llevarlos a cabo es un desperdicio.  No seas un acumulador en tu tablero de proyecto, deja ir las cosas que no necesitas.

Autor imagen: Rosmarie Voegtli