Idea principal

Nadie, delante de su pantalla, se pregunta si sufre un defecto, una capacidad ausente, una capacidad mal hecha o una capacidad que no responde a su necesidad. Constata que no consigue hacer aquello a lo que venía.

La categoría del ticket es una información de fabricación. Describe el origen del problema, no su efecto. Un software sin ningún defecto técnico puede ser doloroso de principio a fin, y el dolor es tan real como el de una regresión.

Lo que queda por analizar está, por tanto, en otra parte: qué dolor, para quién, con qué frecuencia, con qué impacto, si es bloqueante, si es normativo, si genera soporte, si destruye la confianza.

La consecuencia sobre el vocabulario de priorización es directa: la distinción entre defecto y funcionalidad es demasiado pobre para sostener un arbitraje. La pregunta útil no es de qué naturaleza es el asunto, sino qué dolor es prioritario a la vista de la estrategia, de los clientes y de la capacidad real.

Capa aportada por "El backlog no es un vertedero: es una herramienta de acción" (2026-06-03).

Por qué es importante

Esto le quita a la categoría el papel que asume de forma espontánea. Puede ayudar a medir el estado del sistema de producción; no puede decidir en lugar del equipo, puesto que no aporta ninguna información sobre el impacto.

Matices y límites

La categoría conserva un valor diagnóstico del lado de la fabricación: una regresión señala un sistema de producción que deja pasar cosas, lo que una petición de capacidad no señala.

Y el dolor es declarativo: se recoge de personas que no siempre lo formulan, o que lo formulan con el vocabulario de la herramienta.

Preguntas abiertas

• ¿Cómo recoger el dolor sin hacerlo pasar por el vocabulario de los tickets, que lo reformatea en categorías?