Agile: ¿Que es refinar el Backlog?

por Publicado el

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 cálculo, un tablero con notas adhesivas o escritos en el pizarrón. El medio en el que lo plasmes importa poco. Lo que debes saber es que el backlog es más 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 más valor aportan deben ir al principio de la lista. No se vale colocar los items al fondo del backlog conforme van apareciendo. Supongamos que estás 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 más 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 esté 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 está 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 está lista, porque sin los insumos no se puede comenzar. El tratamiento que le des puede variar según la metodología que uses.

Si estás 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 empleas Scrum, esto sería un poco más 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 último 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 más 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 recalcular con más exactitud el esfuerzo necesario para una tarea. Es un ejercicio muy sano hacer recálculo del tamaño y del esfuerzo en una actividad en 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 cuáles 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 del 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 específico 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 necesaria 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. ¿Qué 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 más 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

Gustavo Sánchez
Últimas entradas de Gustavo Sánchez (ver todo)

Publicado por Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.