¿Tu equipo está pagando deuda técnica en cada sprint?

El sprint review se convierte en un déjà vu. El equipo se comprometió a cinco historias, cerró tres, y dos quedaron "casi terminadas". Nadie falló. Nadie se escaqueó. Simplemente, las cosas tardaron más de lo previsto.

Cuando esto pasa una vez, es una estimación optimista. Cuando pasa tres sprints seguidos, hay algo debajo.

Ese algo, en la mayoría de los casos, tiene un nombre: deuda técnica. No la deuda obvia —la que todo el mundo señala y nadie arregla—, sino la invisible. La que se manifiesta como lentitud, como imprevistos, como horas que desaparecen sin que nadie sepa exactamente dónde fueron.

Por qué la deuda técnica no aparece en tu backlog

La mayoría de equipos no rastrean la deuda técnica de forma explícita. No hay un ticket que diga "perder cuatro horas entendiendo un módulo que nadie documentó". Ni uno que diga "rehacer la mitad del trabajo porque una dependencia desactualizada genera conflictos".

Esas horas se diluyen dentro de los tickets de producto. Una historia estimada en cinco puntos acaba costando ocho, y nadie investiga por qué. El equipo asume que estimó mal. El product owner asume que el equipo es más lento de lo que debería.

Según el informe State of DevOps de DORA, los equipos de alto rendimiento dedican menos del 15% de su tiempo a trabajo no planificado. Los equipos con deuda técnica alta pueden superar el 40%. Esa diferencia no aparece en ningún gráfico de velocidad. Pero explica por qué el roadmap se retrasa sprint tras sprint.

El primer problema de la deuda técnica en el delivery no es que exista. Es que nadie la mide.

Las señales que indican que estás pagando intereses

No necesitas una auditoría de código para detectar que la deuda técnica está afectando al delivery. Hay señales que cualquier product owner, engineering manager o CTO puede identificar observando el día a día del equipo.

La velocidad del sprint baja sin razón aparente. El equipo no ha cambiado, el scope es similar, las tecnologías son las mismas. Pero cada sprint entrega menos. La curva de velocidad desciende de forma gradual, no abrupta.

Es como un grifo que gotea: no lo notas hasta que ves la factura del agua.

Las estimaciones fallan sistemáticamente hacia arriba. Todo tarda más de lo previsto. No un 10% más —un 50% o un 100% más. Y no porque el equipo estime mal, sino porque cada ticket arrastra un coste oculto que no se ve hasta que alguien abre el código.

Los bugs aparecen en zonas que nadie tocó. Cambias el módulo de pagos y se rompe la notificación de emails. Eso indica acoplamiento oculto: módulos que dependen entre sí de formas que nadie documentó ni previó. Es una de las formas más costosas de deuda técnica porque convierte cada cambio en una lotería.

El equipo dedica tiempo a "investigar" antes de poder trabajar. Si antes de desarrollar una feature el equipo necesita dos días para entender el código existente, leer commits antiguos y hablar con la persona que escribió ese módulo hace tres años, estás pagando intereses. Ese tiempo de arqueología no es desarrollo: es el peaje de la deuda.

Los pull requests se agrandan sin que el scope crezca. Una historia de dos puntos genera un PR de 800 líneas porque, para implementar el cambio, hubo que mover, renombrar y corregir código alrededor. El volumen del PR no refleja la complejidad de la feature, sino la complejidad de la deuda.

Cómo medir el impacto real en el delivery

Detectar las señales es el primer paso. Pero para actuar, necesitas cuantificar. No hace falta un sistema sofisticado. Basta con medir unas pocas cosas durante tres o cuatro sprints consecutivos.

Ratio de trabajo planificado vs. no planificado

De todo el trabajo que hace tu equipo en un sprint, ¿cuánto estaba en el plan y cuánto apareció sobre la marcha? Bugs urgentes, correcciones necesarias para avanzar, investigaciones imprevistas, ajustes por dependencias rotas.

Todo eso es trabajo no planificado.

Si el trabajo no planificado supera el 25-30% del sprint de forma sostenida, la deuda técnica probablemente está detrás. Medir esto es sencillo: al cerrar cada sprint, clasifica los tickets completados como "planificados" o "emergentes". En tres sprints tienes una tendencia.

Tiempo de ciclo por tipo de historia

El cycle time —el tiempo desde que alguien empieza a trabajar en un ticket hasta que está en producción— es uno de los indicadores más reveladores. Pero el número absoluto dice poco. Lo que importa es comparar.

Si las historias en módulos nuevos (código limpio, sin legacy) tienen un cycle time de dos días, y las historias en módulos antiguos tardan seis días de media, la diferencia es deuda técnica pura. No es que un módulo sea más complejo conceptualmente: es que el código hace todo más lento.

Herramientas como Jira, Linear o Shortcut ya rastrean el cycle time. Solo necesitas segmentar por área del producto. Si tu equipo trabaja con Django como backend, por ejemplo, puedes comparar el cycle time de los módulos legacy frente a los más recientes.

Factor de expansión de los tickets

Mide la diferencia entre la estimación original y el esfuerzo real. Si un ticket estimado en 3 puntos acaba costando 8, el factor de expansión es 2.6x. Haz la media por sprint y por área del código.

Un factor de expansión superior a 1.5x de forma consistente indica que las estimaciones no están mal: indica que hay trabajo oculto que no se puede prever hasta que abres el código. Ese trabajo oculto es deuda técnica manifestándose.

Tasa de reapertura de tickets

¿Con qué frecuencia se reabre un ticket que ya estaba cerrado? Una tasa de reapertura alta —por encima del 10-15%— sugiere que el código es frágil, que los tests son insuficientes o que los cambios tienen efectos secundarios inesperados. Todo eso es deuda técnica.

Las trampas que disimulan el problema

La deuda técnica en el delivery es especialmente peligrosa porque los equipos y las organizaciones desarrollan mecanismos inconscientes para disimularla.

Reducir el scope en lugar de cuestionar la velocidad. Si el equipo entrega menos, la solución fácil es planificar menos. El sprint se adapta a la velocidad reducida y el problema desaparece del radar. Pero no ha desaparecido: simplemente has normalizado que tu equipo entregue la mitad de lo que podría.

Confundir actividad con progreso. Los desarrolladores están ocupados, los PRs se mueven, los dailies reportan avances. Pero el producto apenas cambia. Hay mucho movimiento y poco desplazamiento. Si midieras cuántas líneas de código del sprint son funcionalidad nueva versus mantenimiento forzado, el resultado te sorprendería.

Culpar a las estimaciones. "Estimamos mal" es la explicación por defecto cuando algo tarda más de lo previsto. Y a veces es cierto. Pero si las estimaciones fallan siempre en la misma dirección y en las mismas áreas del código, el problema no es la estimación.

Normalizar los bugs como "parte del proceso". Todos los proyectos tienen bugs. Pero si tu equipo dedica más de un 15-20% del sprint a corregir defectos en código existente (no bugs de features nuevas), la base de código está generando trabajo de mantenimiento que compite con el desarrollo de producto.

Qué hacer cuando confirmas el problema

Si después de medir durante unos sprints las cifras confirman lo que ya sospechabas, el siguiente paso no es abrir un ticket épico de "arreglar la deuda técnica". Es hacer visible el coste.

Traduce la deuda a lenguaje de negocio

Los datos técnicos convencen a los desarrolladores. Al resto de la organización necesitas hablarle en otro idioma.

No digas "tenemos acoplamiento alto y cobertura baja". Di: "cada feature nueva nos cuesta un 60% más de lo que debería porque el código base nos frena. En los últimos tres meses, eso equivale a X semanas de desarrollo perdidas, que podrían haberse dedicado a las funcionalidades que el negocio necesita".

El informe de Stripe de 2018 estimó que la deuda técnica le cuesta a la industria global de software 85.000 millones de dólares anuales en productividad perdida. No necesitas cifras tan grandes: basta con calcular cuántas horas pierde tu equipo al mes en trabajo generado por la deuda y multiplicar por el coste/hora.

Crea un mapa de calor de la deuda

No toda la deuda afecta al delivery por igual. Cruza dos variables: frecuencia de modificación y coste de cada modificación. Los módulos que se tocan mucho y cuestan mucho cada vez que se tocan son la prioridad.

Herramientas como CodeScene o SonarQube pueden generar estos mapas de forma automatizada. Pero incluso sin herramientas, puedes hacerlo manualmente: pregunta al equipo cuáles son los tres archivos o módulos que más temen modificar. La respuesta suele coincidir con las zonas de mayor deuda.

Reserva capacidad, no la negocies

La reducción de deuda técnica no debería competir con las features en la priorización del backlog. Debería tener su propia capacidad reservada. Un 15-20% del sprint destinado exclusivamente a mejoras técnicas es un punto de partida razonable.

Si la deuda es severa, puede que necesites más. Pero empieza por ahí. Lo importante es que sea un compromiso fijo, no algo que se sacrifica cada vez que aparece una feature urgente. Porque siempre hay una feature urgente.

Mide la mejora sprint a sprint

Si empiezas a invertir en reducir deuda, necesitas demostrar que esa inversión produce resultados. Usa las mismas métricas que usaste para diagnosticar: velocidad, cycle time, factor de expansión, tasa de reapertura. En cuatro o cinco sprints deberías ver movimiento.

Si no lo ves, puede que estés atacando la deuda equivocada. Vuelve al mapa de calor y reajusta las prioridades.

Cuándo el equipo necesita refuerzos

Hay una situación que se repite: el equipo sabe exactamente dónde está la deuda, sabe qué debería hacer, pero no tiene margen. El 100% de su capacidad se consume en mantener el producto funcionando y entregar lo mínimo del roadmap. No hay un 15% que reservar porque no hay un 15% disponible.

En esos casos, un equipo externo especializado en refactoring y modernización de sistemas puede asumir la reducción de deuda mientras el equipo interno sigue enfocado en producto. No es ceder el control: es ampliar la capacidad durante el tiempo necesario para salir del agujero.

La clave es que el equipo externo trabaje integrado con el interno, no en paralelo. Comparten codebase, comparten dailies, comparten criterio. La deuda se reduce sin fragmentar el conocimiento.

La deuda siempre se paga

Puedes ignorar la deuda técnica durante un tiempo. A veces durante bastante tiempo. Pero el interés compuesto funciona igual en software que en finanzas: cuanto más esperas, más caro sale.

La diferencia entre un equipo que entrega con consistencia y uno que siempre va por detrás rara vez está en el talento. Está en el estado de la base de código sobre la que trabajan. Un buen equipo con una base de código limpia rinde. El mismo equipo con una base de código endeudada sobrevive.

Medir el impacto de la deuda en tu delivery no requiere herramientas caras ni procesos complejos. Requiere dejar de aceptar que "las cosas tardan lo que tardan" y empezar a preguntar por qué. Los datos suelen estar ahí. Solo falta mirarlos.