El backlog que se refinó hasta morir (y cómo un equipo lo arregló)
Un equipo de software distribuido al que llamaré la cuadrilla Atlas pasó la segunda mitad de 2020 trabajando por completo desde casa. Para enero de 2021 tenía un problema que no lograba nombrar. Su backlog de producto se había hinchado a más de cuatrocientos elementos, cada uno cuidadosamente redactado, estimado y etiquetado. Y aun así, la planificación de sprint se alargaba, las mismas preguntas surgían a mitad del sprint, y el equipo rara vez terminaba lo que pronosticaba. Refinaban sin parar, y eso empeoraba las cosas.
La Guía de Scrum describe el refinamiento del backlog de producto como el acto continuo de descomponer y definir mejor los elementos en piezas más pequeñas y precisas, añadiendo detalles como descripción, orden y tamaño. No es un evento obligatorio aparte, ni un concurso de documentación. Atlas lo había convertido en uno sin darse cuenta.
Cómo se torció el refinamiento
Al trabajar en remoto, el equipo había sustituido las conversaciones de pasillo por tickets escritos, lo cual era sensato. Pero se pasó de la raya. Cada idea de cualquiera se convertía en un elemento del backlog. Elementos del fondo, a meses de trabajarse, se estimaban en detalle. Las sesiones de refinamiento cubrían toda la lista en vez de la siguiente porción. El resultado fue un backlog que parecía exhaustivo pero era casi todo ruido, y un equipo que confundía escribir sobre el trabajo con entenderlo.
Refinar elementos demasiado lejanos para ser estables, de modo que el detalle quedaba obsoleto al empezar el trabajo.
Tratar las estimaciones como compromisos, lo que hacía a todos reacios a dividir o reordenar elementos.
Dejar crecer el backlog sin retirar nunca los elementos que ya no reflejaban el objetivo de producto.
Lo que de verdad lo solucionó
El Product Owner, responsable del backlog de producto y de su ordenamiento, retomó la poda. Juntos, el equipo acordó un ritmo más ligero y un propósito más claro para el refinamiento.
Refinar la cima, no el todo. Centraron el refinamiento en los elementos con mayor probabilidad de entrar en el siguiente sprint o los dos siguientes, dejando los inferiores como simples bosquejos.
Hacer los elementos listos, no perfectos. Un elemento se consideraba listo cuando los desarrolladores lo entendían lo bastante bien para pronosticarlo con confianza, no cuando cada campo estaba relleno.
Podar sin piedad. Todo lo que no se había movido en tres meses y ya no servía al objetivo de producto se archivaba. El backlog bajó de cien elementos.
Refinar en porciones cortas y frecuentes. Dos sesiones de treinta minutos por semana, con cámaras encendidas y un elemento tratado a la vez, sustituyeron a la reunión maratónica.
En tres sprints, la planificación era más corta, los pronósticos más fiables, y las sorpresas a mitad del sprint cayeron de forma notable. La lección no es que el refinamiento sea opcional. Es que el refinamiento es una conversación orientada al entendimiento compartido del próximo trabajo, no un museo de backlog que curar para siempre.
Si su equipo se ahoga en un backlog que crece más rápido de lo que entrega, la asesoría de XNM en ejecución de programas y proyectos puede ayudarle a construir hábitos de refinamiento que mantengan el trabajo claro y al equipo en marcha.