Backlog podrido: límpialo sin perder un día entero

Por qué tu backlog se pudre (y no es tu culpa)

Un backlog siempre empieza limpio. Veinte ítems, un equipo que sabe por qué está cada uno. Luego crece. A los 200 ítems, se vuelve penoso. Más allá de 500, se convierte en un pasivo.

El problema no es el volumen. Es que todo está al mismo nivel. Una migración de autenticación y un cambio de color de botón terminan uno al lado del otro, disputándose el mismo slot de prioridad. Como resume un Head of Product citado por ProdPad, su backlog se había convertido en «un cementerio con una barra de búsqueda»: más de 400 ítems acumulados en dos años, todos etiquetados como «ideas».

Cuando todo está plano, tres vicios reaparecen sistemáticamente:

• La priorización por volumen. Gana el ítem con más votos o el defensor más ruidoso. Una fricción UI menor mencionada diez veces pasa por delante de una decisión de arquitectura que nadie fuera de engineering entiende.
• El sesgo de recencia. Lo que se habló más recientemente parece lo más importante. El backlog se convierte en una cola de espera, ya no en una herramienta de estrategia.
• La falsa equivalencia. Se aplica el mismo scoring RICE a todo, como si el «Reach» de una migración de plataforma significara lo mismo que el de un tooltip. El número da una ilusión de rigor, pero las entradas no son comparables.

La buena noticia: no necesitas una reunión de tres horas para arreglar esto. Tres pasadas cortas, repetidas con regularidad, son suficientes.

Pasada 1 — Eliminar: 20 minutos, sin debate

Objetivo: quitar todo lo que nunca se hará. Regla simple: si nadie puede nombrar un usuario o un objetivo concreto al que sirva este ítem, sale.

Concretamente, eliminas:

• Los ítems creados hace más de seis meses, nunca priorizados, que nadie recuerda.
• Las ideas copiadas y pegadas de un hilo de Slack, sin contexto ni problema identificado.
• Los «quizá deberíamos…» sin propietario ni fecha límite.
• Los duplicados disfrazados (volvemos a ellos en la pasada 2).

No intentes archivar limpiamente. Elimina. Si la idea era buena, volverá — y esta vez con un problema real detrás.

En una herramienta como Ever Earlier, esta pasada es mecánica: filtras por fecha de creación y por ausencia de prioridad, eliminas en masa. Sin reunión, sin hoja de Excel que mantener.

Pasada 2 — Fusionar: detectar los duplicados y agruparlos

Después de la eliminación, a menudo quedan ítems que describen la misma necesidad desde tres ángulos diferentes. Es normal: tres personas se encontraron con el mismo problema en tres momentos.

La fusión se hace a nivel del problema, no de la solución. Dos ítems que proponen soluciones diferentes al mismo problema son solo uno.

Ejemplo concreto. Tres ítems separados:

• «Poder ver quién ha modificado una tarjeta»
• «Historial de cambios en una tarea»
• «Saber cuándo se ha movido una story»

Un solo problema: la trazabilidad de las modificaciones. Una sola user story tras la fusión, con un criterio de aceptación claro: «Como jefe de proyecto, veo la lista cronológica de las modificaciones de una tarjeta, con autor y fecha, para entender qué ha cambiado desde mi última visita.»

En Ever Earlier, el registro de actividad ya cubre esta necesidad del lado de la herramienta — pero el ejercicio vale para tu propio backlog. Una story fusionada, con prioridad, puntos y criterios de aceptación, reemplaza tres ítems difusos. Divides el ruido por tres.

Pasada 3 — Priorizar: primero el valor, después el tamaño

Ahora quedan ítems que merecen una decisión. Dos preguntas, en este orden:

1. ¿Qué valor? ¿A quién impacta, a cuántos y hasta qué punto? Si no puedes responder en una frase, el ítem no está listo — vuelve a discusión, no a sprint.
2. ¿Qué tamaño? Una story de 13 puntos que arrastra desde hace tres sprints no es una story, es un proyecto disfrazado. Divídela.

Aquí es donde las user stories estructuradas ahorran tiempo. Una story con prioridad, estimación en puntos y criterios de aceptación se juzga en treinta segundos. Una story sin estos elementos desencadena una discusión de diez minutos en cada planning.

Un principio útil, tomado de la teoría de las restricciones: no sobrecargues el cuello de botella. Si tu equipo mergea o entrega de 20 a 35 ítems al mes, un backlog activo de 200 ítems representa aproximadamente 6,7 meses de espera en promedio. No es un backlog temporal, es lo que el sistema produce a esa carga. Reducir el trabajo en curso es más eficaz que añadir revisiones.

El refactoring no va al backlog

Tentación clásica después de una gran limpieza: añadir «stories de refactoring» para recuperar el retraso técnico. Ron Jeffries explica por qué es una mala idea: pedirle tiempo al product owner para reparar lo que uno mismo ha estropeado es difícil de vender, y el resultado decepciona — se limpia lo que se ve, en el tiempo que se tiene, nunca lo suficiente.

El buen enfoque es más simple: con cada nueva feature, se limpia el código que se atraviesa. No se rodean las zarzas, se desbroza una parte. A veces la feature tarda un poco más. A menudo no, porque la limpieza ayuda desde la primera feature que pasa por ahí.

Consecuencia para tu backlog: no pongas líneas de «refactoring». Pon features, y deja que la limpieza se haga dentro.

La cadencia importa más que la profundidad

Una pasada de 20 minutos cada dos semanas vale más que una sesión de tres horas cada seis meses. El backlog no se ensucia de golpe, tampoco se limpia de golpe.

Tres reglas para mantenerlo:

• Una pasada, un objetivo. Eliminar es eliminar. No se prioriza mientras se elimina.
• Un responsable por pasada. En general el product manager o el jefe de proyecto, no todo el equipo.
• Una herramienta que no añada fricción. Si limpiar el backlog exige más esfuerzo que llenarlo, no lo harás.

En Ever Earlier, las user stories con prioridad, puntos y criterios de aceptación hacen que esta pasada sea rápida: ves de inmediato qué ítems están listos, cuáles son vagos, cuáles ya no tienen sentido. El backlog y los sprints viven en el mismo lugar, así que no duplicas nada.