Backlog que crece: la regla entradas/salidas

El backlog que crece: tres síntomas que no engañan

Abres tu tablero el lunes por la mañana y la primera columna tiene 400 tarjetas. Haces scroll. Lo cierras. Añades una más. Es la señal de que tu backlog ya no es una herramienta de priorización, sino un diario.

Tres síntomas se repiten:

• El ritual de planificación que se eterniza. Cada sprint, se recorre la lista de nuevo, se argumenta, se elige según quién habló más fuerte esta semana.
• Los ítems viejos que nunca mueren. Una idea depositada hace ocho meses sigue «en espera» sin que nadie sepa por qué.
• Las comparaciones absurdas. Se ponen lado a lado «migrar la autenticación» y «cambiar el color del botón de onboarding» como si fuera el mismo tipo de decisión.

Estos tres síntomas vienen de una misma causa estructural: un backlog plano. Cuando todo está al mismo nivel, cada conversación de prioridad empieza de cero.

Separar las altitudes antes de medir cualquier cosa

El modelo de los flight levels describe tres altitudes de decisión: estratégica (dónde invertir), de coordinación (cómo circula el trabajo entre los equipos) y operativa (cómo ejecuta un equipo). Cada altitud tiene su ritmo, sus decisores y su definición de «terminado».

Cuando una organización gestiona todo a una sola altitud, las decisiones estratégicas quedan ahogadas en debates operativos, y ajustes tácticos adquieren la misma solemnidad que una apuesta de plataforma. Nada avanza al ritmo adecuado.

En concreto, antes de contar las entradas y las salidas, haz la criba:

• Estratégica: «¿Hay que reemplazar nuestro sistema de pago?» — decisión trimestral, poca gente en la sala.
• De coordinación: «¿Qué iniciativa aborda qué problema del cliente este trimestre?» — revisión mensual.
• Operativa: «¿Qué user story pasa a este sprint?» — decisión semanal del equipo.

Un ítem que no pertenece a la altitud de la reunión en curso no tiene nada que hacer allí. Este simple filtro elimina la mitad de los debates estériles.

Por qué un backlog saturado ralentiza de forma exponencial

La teoría de colas aplicada al desarrollo de producto da un resultado contraintuitivo: cuando un recurso se acerca al 100 % de utilización, la cola crece de forma exponencial, no lineal. La fórmula M/M/1 se escribe espera = utilización / (1 − utilización). Al 50 % de utilización, la espera vale 1×. Al 80 %, 4×. Al 90 %, 9×. Al 95 %, 19×.

Dicho de otro modo: cuanto más aprietas tu capacidad, más explota la cola. No vas a alcanzar una exponencial trabajando más.

La ley de Little da la otra mitad del cuadro: tiempo de ciclo = trabajo en curso / rendimiento. Un proyecto open source documentado tenía unas 200 pull requests abiertas y fusionaba 20 a 35 PR al mes: el tiempo de ciclo medio resultaba de unos 6,7 meses. No es un backlog temporal, es el comportamiento normal del sistema con esa carga.

El mismo razonamiento se aplica a tu backlog: si tienes 180 ítems abiertos y entregas 6 por sprint, tu tiempo de travesía medio es de 30 sprints. Ese número, mostrado en reunión, suele cambiar la conversación más eficazmente que un debate de opiniones.

La tabla de seguimiento entradas/salidas, en cinco columnas

No necesitas una herramienta sofisticada. Una hoja de cálculo compartida basta, siempre que se rellene cada semana, a la misma hora, por la misma persona.

Cinco columnas:

1. Semana — la fecha del registro.
2. Entradas — número de ítems añadidos al backlog esa semana.
3. Salidas entregadas — ítems pasados a «terminado» y realmente utilizables.
4. Salidas abandonadas — ítems cerrados explícitamente sin ser entregados.
5. Total abierto — el saldo al final de la semana.

Dos ratios se calculan solos:

• Ratio entradas/salidas = entradas ÷ (entregadas + abandonadas). Por encima de 1, el backlog crece. Por debajo de 1, se reduce.
• Edad mediana de los ítems abiertos — la mitad de los ítems abiertos son más viejos que ese número de semanas. Si supera 12, tu backlog es un archivado, no un plan.

El número que desencadena una acción es el ratio entradas/salidas en cuatro semanas consecutivas. Si se mantiene por encima de 1,2, tienes un problema de techo, no de productividad.

Una plataforma como Ever Earlier muestra un registro de actividad por tarjeta y por columna: puedes reconstruir estas cifras sin llevar una hoja de cálculo paralela, filtrando las tarjetas creadas y terminadas en el periodo.

Fijar un techo por sprint (y mantenerlo)

Un techo de entradas no es un límite a la imaginación. Es un límite al trabajo aceptado. La distinción es esencial cuando lo anuncias.

Tres reglas simples:

• Techo de entradas: por ejemplo 5 nuevos ítems por sprint y por equipo. Más allá, el ítem va a una lista «por cualificar» que no es el backlog activo.
• Umbral de salida obligatorio: todo ítem abierto desde hace más de 8 sprints o se planifica en los 2 sprints siguientes, o se cierra. Sin zona gris.
• Presupuesto de limpieza: 10 a 15 % de la capacidad del sprint reservada al grooming y al cierre de ítems obsoletos. No es tiempo perdido, es lo que impide que la cola explote.

El techo debe ser visible. En un tablero Kanban, basta una columna «Por cualificar» con un contador. Cuando está llena, ya no se discute la adición, se discute qué se retira.

Cuidado con no confundir techo de entradas y techo de trabajo en curso. El primero limita lo que entra en el backlog; el segundo limita lo que está en ejecución. Ambos son útiles, pero no se sustituyen.

Decir no sin conflicto: cuatro guiones para reutilizar

La mayoría de los conflictos en torno al backlog no vienen de un desacuerdo sobre el valor de la idea, sino de un malentendido sobre lo que significa «añadir al backlog». Reencuadra la conversación sobre el coste, no sobre el mérito.

Guión 1 — Cuando un directivo añade una idea en reunión

«Anoto la idea, es legítima. Para meterla en el sprint en curso, hay que retirar otra cosa: aquí están los tres ítems que están al mismo nivel de prioridad. ¿Cuál desplazamos?»

No rechazas. Haces visible el coste.

Guión 2 — Cuando una parte interesada insiste en la urgencia

«De acuerdo con la urgencia. Nuestro techo de entradas de este sprint está alcanzado. Dos opciones: la tratamos en el sprint siguiente con prioridad alta, o desplazamos el ítem X que estaba previsto. ¿Cuál prefieres?»

Guión 3 — Cuando un ítem duerme desde hace meses

«Este ítem está abierto desde hace seis meses sin haber sido planificado. ¿Sigue siendo actual? Si sí, lo planificamos en los dos próximos sprints. Si no, lo cerramos y guardamos una nota para el histórico.»

Guión 4 — Cuando te reprochan «decir no a todo»

«No decimos no a las ideas, decimos no al apilamiento. Cada ítem que añadimos sin retirar otro alarga el plazo de entrega de todos los demás. Aquí está el número de la semana.»

Estos cuatro guiones funcionan porque desplazan la decisión: ya no es «tu idea contra la mía», es «qué ítem sale para que este entre».

¿Y el refactoring? No va al backlog

Pregunta clásica: ¿hay que crear user stories de refactoring en el backlog? La respuesta, formulada hace mucho tiempo por Ron Jeffries, sigue siendo válida: es una mala idea.

Un gran frente de limpieza es difícil de vender, y cuando se vende, rinde menos de lo previsto tras un largo plazo. El buen enfoque es incremental: cuando construyes la próxima funcionalidad, en lugar de rodear las zonas problemáticas, limpias el camino que atraviesas. Ignoras el código que no tienes que tocar.

A veces la funcionalidad tarda un poco más. A menudo no, porque la limpieza ayuda desde la primera feature que pasa por allí. Y la vez siguiente, el beneficio es inmediato.

Consecuencia práctica para tu backlog: no crees ítems «deuda técnica» genéricos. Añade más bien un criterio de aceptación a la user story en curso, del tipo «el módulo X está cubierto por tests antes de la puesta en producción». La limpieza se convierte en una propiedad de la feature, no en un frente separado.

El ritual semanal: 30 minutos, cinco preguntas

Una tabla de seguimiento no sirve de nada si no se lee. Bloquea 30 minutos por semana, fuera de las ceremonias ágiles clásicas, con la persona que mantiene el backlog.

Cinco preguntas, en este orden:

1. ¿Cuántos ítems han entrado esta semana? ¿Por quién?
2. ¿Cuántos han salido, entregados o abandonados?
3. ¿Cuál es el ratio entradas/salidas en las cuatro últimas semanas?
4. ¿Qué ítems abiertos tienen más de 8 sprints? ¿Qué hacemos con ellos?
5. ¿El techo de entradas del próximo sprint ya está alcanzado?

Si la respuesta a la pregunta 5 es sí, la siguiente reunión de planificación empieza por una decisión de retirada, no por una adición. Es lo que distingue un backlog vivo de un cementerio con barra de búsqueda.

En Ever Earlier, puedes filtrar las tarjetas por fecha de creación y por estado en el registro de actividad, y luego exportar la vista para la reunión. El agente IA que genera user stories a partir de epics sigue siendo útil, siempre que no se use para llenar el backlog más rápido de lo que se vacía.