Historia técnica
Una historia técnica es un elemento del backlog que describe trabajo sin un usuario final visible (una migración, una reindexación, una refactorización). El problema no es el trabajo, sino cómo se escribe: la salida deshonesta es inventar un usuario («como servidor, quiero…»), y las honestas son tres. Se distingue de la tarea disfrazada en que la historia técnica se puede priorizar por sí sola.
«Como servidor, quiero un índice en la tabla de facturas, para responder más rápido» existe en casi todos los backlog del mundo y no comunica nada. El usuario falso no es un descuido de redacción: es la consecuencia de una norma mal entendida. Cuando la organización exige que todo elemento tenga forma de historia, el equipo cumple la forma y renuncia al contenido. El daño es doble: la historia no permite priorizar, porque no dice a quién sirve ni cuánto vale, y oculta la conversación que sí hacía falta, que era técnica y con criterio técnico.
Las tres salidas honestas
- Encontrar el beneficiario real y su valor. Muchas veces existe y no se ha buscado. El índice de la tabla de facturas no sirve al servidor: sirve al autónomo que espera cuatro segundos cada vez que abre su listado, y el valor se enuncia en abandono o en consultas al soporte. Cuando el beneficiario aparece, el elemento vuelve a ser una historia legítima.
- Enunciarlo en claro como trabajo técnico, con su justificación económica: «reindexar el almacén de facturas para sostener el crecimiento previsto del próximo año». Cabe llamarlo elemento técnico, funcionalidad al estilo FDD, spike o habilitador, y ninguna de esas formas necesita plantilla.
- Convertirlo en restricción o criterio de la Definition of Done. Cuando el trabajo expresa una cualidad que debe cumplirse siempre (tiempo de respuesta, accesibilidad, cifrado), su sitio no es un elemento que se hace una vez, sino un criterio que se verifica en cada incremento (véase Requisitos no funcionales).
La salida deshonesta —inventar un usuario— cumple el formulario y desactiva las tres decisiones que había que tomar: quién se beneficia, cuánto vale y cómo se comprueba.
Historia técnica honesta frente a tarea disfrazada
Es la distinción que más se usa en el refinamiento, y tiene una prueba sencilla:
| Historia técnica honesta | Tarea disfrazada |
|---|---|
| Produce un cambio que alguien identificable necesita. | Es un paso necesario de otra cosa. |
| Se puede posponer, descartar y explicar a quien no es técnico. | No se puede posponer sin bloquear la historia a la que sirve. |
| Tiene sentido fuera del contexto de otro elemento. | No tiene sentido fuera del contexto de otro elemento; su sitio es dentro de él. |
Humanizing Work resume la regla: si el elemento no tiene sentido fuera del contexto de otro, es una tarea. Aplicar esta prueba limpia mucho el backlog, porque buena parte de los elementos técnicos que lo abarrotan son tareas de historias que ya están en la lista.
Deuda técnica y equipos de plataforma
La deuda técnica, enunciada como trabajo sin beneficiario, siempre pierde frente a una funcionalidad nueva. Enunciada con su efecto observable —cuánto ralentiza cada cambio, cuántas incidencias produce— compite en igualdad. La formulación que funciona es la del interés: en lugar de «hay que refactorizar el módulo de facturación», «cada cambio en facturación cuesta el doble y produce una incidencia de cada tres, y seguirá así mientras no se reordene». Así la decisión es de producto, no una concesión al equipo técnico.
Hay un caso donde el «usuario técnico» no es una ficción: los equipos de plataforma, cuyo producto es una plataforma interna. Ahí quien desarrolla es un cliente real, con necesidades y alternativas, y las historias con desarrolladores como usuarios son legítimas y necesarias.
La historia técnica y la IA
La generación de código asistida puede producir deuda técnica con rapidez, porque el código plausible no siempre es mantenible. Enunciar el trabajo de saneamiento con su interés observable es aún más importante cuando el volumen de código crece deprisa.
Un dato con fuente verificada: el estudio METR de julio de 2025 observó que dieciséis desarrolladores experimentados tardaban un 19 % más al trabajar con IA en sus propios repositorios, aunque creían haber ido un 20 % más rápido. La percepción de velocidad no equivale a velocidad, y la deuda que se acumula sin medir la agrava.
Error frecuente
Inventar un usuario técnico. «Como base de datos, quiero…» cumple el formulario y desactiva la priorización, además de impedir la conversación técnica que sí hacía falta. Ante un trabajo sin usuario visible, hay que elegir una de las tres salidas honestas: buscar el beneficiario real, enunciarlo en claro como trabajo técnico con su razón económica, o convertirlo en criterio de la Definition of Done.
Recursos
🏦 Skill User storiesState of the art y guía de desarrollo · Skill Arena
📄 Historias de usuario v.5.0Descarga gratuita · Scrum Manager · ene 2026
📄 Scrum Master en equipos con IA v.1.0Descarga gratuita · Scrum Manager
Referencias
- Cohn, Mike. (2004). User Stories Applied. Addison-Wesley.
- Skelton, Matthew; Pais, Manuel. (2019). Team Topologies. IT Revolution.
- METR. (2025). «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity».
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.