El coste oculto de los tickets vagos en Jira
Un ticket vago de Jira rara vez parece peligroso al principio. El problema real aparece más tarde, cuando distintas personas completan los huecos con supuestos distintos y varios días de trabajo concentrado acaban apuntando a lo equivocado.
Por qué sobreviven los tickets vagos
Una ingeniera de backend toma un ticket el lunes por la mañana. El título parece concreto: "Añadir notificaciones al usuario sobre actualizaciones del pedido". La descripción tiene dos frases y un enlace a un hilo de Slack de hace tres semanas. A simple vista parece suficiente. Ella pasa tres días montando un flujo de correos que se activa con cada cambio de estado del pedido.
El jueves, durante la revisión del PR, la PM entra y dice: "No me refería a eso. Solo necesitábamos notificaciones dentro de la aplicación para eventos de envío, y además los usuarios tenían que poder desactivarlas". Nadie se equivocó. Nadie trabajó mal. El ticket simplemente nunca sacó a la luz las decisiones que escondía.
Nadie redacta un ticket vago a propósito. Se escribe en dos minutos entre una reunión y otra, con la intención sincera de volver después y completarlo. Ese momento nunca llega. Quien lo escribe tiene todo el contexto en la cabeza. Sabe qué eventos importan, qué canales está contemplando y a qué usuarios afecta.
Nada de eso llega a la página, porque parece obvio. Para el resto del equipo, no lo es.
Jira empeora esto precisamente porque lo pone muy fácil. No hay un campo obligatorio que pregunte qué queda explícitamente fuera de alcance. No hay ninguna barrera que rechace una descripción de menos de veinte palabras. Puedes escribir tres palabras en el resumen, dejar vacía la descripción y pulsar Crear. Jira no se resiste. Eso es una ventaja y una trampa a la vez. El resultado es un backlog lleno de tickets que parecen completos a simple vista y solo muestran su vaguedad cuando alguien ya ha empezado a construir.
Qué contiene de verdad un plan listo para construir
La mayoría de los tickets responden una sola pregunta: ¿qué queremos? Un plan listo para construir responde seis.
| Parte | Qué responde |
|---|---|
| Alcance | Qué entra y qué queda fuera de forma explícita |
| Restricciones | Qué no puede cambiarse ni romperse |
| Pasos | Qué tiene que ocurrir y en qué orden |
| Casos límite | Qué pasa cuando la vía evidente falla |
| Dependencias | Qué tiene que existir antes |
| Definición de terminado | Cómo sabrá todo el mundo que el trabajo está realmente acabado |
No hace falta usar esto en cada arreglo diminuto del backlog. Pero cualquier cosa que vaya a entrar en un sprint, cualquier trabajo que probablemente vaya a consumir más de unas pocas horas de alguien, necesita estas preguntas resueltas antes de empezar. El alcance es justo la parte que más se omite. Definir lo que queda fuera parece innecesario cuando el equipo está concentrado en lo que sí va dentro. Pero ahí es donde empieza una cantidad sorprendente de retrabajo.
Las restricciones son los requisitos silenciosos:
- No romper el flujo actual de correos sobre pedidos.
- Mantenerse dentro del servicio actual de notificaciones.
- No añadir infraestructura nueva en este sprint.
Estos detalles rara vez se escriben porque quien redacta supone que todo el mundo ya los conoce. No es así. Y la definición de terminado es la línea que separa "creo que ya está" de "todos estamos de acuerdo en que ya está". Una buena definición de terminado se puede observar y se puede comprobar.
Las preguntas van antes que la estructura
En algún momento, toda instancia de Jira pasa por el mismo ciclo. Alguien añade una plantilla de descripción con apartados como Resumen, Criterios de aceptación, Notas técnicas y Fuera de alcance. Durante unas semanas, la gente la rellena. Después, el mismo lenguaje vago que antes vivía en una descripción vacía empieza a repartirse por más casillas con etiqueta. Mejoró la estructura. No mejoró el pensamiento.
Las plantillas no resuelven el problema porque el problema no es estructural. Es cognitivo. Quien redacta no sabe qué se está dejando fuera. Una sección vacía titulada Casos límite no ayuda a quien todavía no ha pensado en los casos límite. Las preguntas sí. Preguntas concretas, específicas, que obliguen a tomar decisiones.
Hay cinco preguntas que hacen especialmente bien ese trabajo:
- ¿Qué cambia en el comportamiento del sistema?
- ¿Quién es la persona principal implicada y qué intenta conseguir?
- ¿Hay algún caso en el que esto no deba suceder?
- ¿Qué se rompe si no lo entregamos?
- ¿Esto aplica a usuarios existentes, a usuarios nuevos o a ambos?
Funcionan porque son lo bastante concretas como para contestarlas y lo bastante amplias como para servir en casi cualquier ticket de funcionalidad. El acto de responderlas ya es planificación. La plantilla es solo el sitio donde acaban esas respuestas.
Ejemplo completo
Así se ve esto en la práctica. El ticket original es mínimo: "Añadir notificaciones al usuario sobre actualizaciones del pedido". La descripción solo dice que el usuario debe recibir una notificación cuando cambie el estado del pedido e incluye una nota para revisar con diseño el tratamiento visual. Eso basta para meterlo en un sprint, pero ni de lejos para construir con seguridad.
Una ronda corta de aclaraciones lo cambia todo:
| Pregunta de aclaración | Respuesta |
|---|---|
| ¿Qué cambios de estado importan? | Solo enviado y entregado |
| ¿Qué canales? | Solo dentro de la aplicación en este sprint |
| ¿Puede el usuario desactivarlas? | Sí, con activación por defecto |
| ¿Qué pasa con usuarios desconectados? | La notificación se deja en cola hasta el próximo inicio de sesión |
| ¿Aplica a pedidos existentes? | No, solo a los nuevos |
| ¿Qué ocurre si falla la entrega? | Reintentar una vez y luego registrarlo |
Quince minutos después, el ticket significa una sola cosa para todo el mundo. La versión final ya tiene un alcance real, restricciones reales, pasos ordenados, casos límite reales y una definición de terminado que puede comprobarse. Es el mismo ticket. La claridad no tiene nada que ver. La diferencia no es una plantilla mejor. Es dedicar un pequeño esfuerzo a preguntar bien antes de empezar a trabajar.
Dónde encaja la IA en este proceso
La IA no escribe tickets. Los tickets los escriben las personas. Pero la IA sí resulta útil en un punto muy concreto del proceso: después de que exista la intención, antes de que la estructura quede cerrada. Un modelo de lenguaje puede leer una descripción vaga y preguntar: "¿Has tenido en cuenta qué pasa cuando el usuario está desconectado?". Puede tomar respuestas sueltas de un hilo de Slack y ordenarlas en alcance, restricciones y pasos. Puede detectar que el plan menciona una migración de base de datos, pero la lista de dependencias no incluye la revisión de las personas adecuadas.
Lo que la IA no hace bien es tomar decisiones de producto por ti. Puede preguntar si esto debería ir por correo, push o dentro de la aplicación. No puede decidir cuál de esas opciones es la correcta para tus usuarios y para este sprint. Puede generar una definición de terminado que suene plausible, pero solo una persona que entienda el producto sabe si esa definición es realmente la adecuada.
El patrón es sencillo: las personas deciden, la IA estructura. Las personas fijan el alcance, la IA detecta huecos. Ese es el patrón, aclarar, planificar y ejecutar, sobre el que está construido Just en Atlassian Marketplace dentro de Jira. El mismo patrón también funciona de forma manual. La IA solo hace el ciclo más rápido.
Tres cosas que puedes aplicar hoy
- Antes del próximo sprint, elige el ticket más vago de tu backlog y plantea las cinco preguntas de este artículo antes de que nadie escriba una línea de código. Casi seguro descubrirás al menos dos decisiones que nadie había advertido que seguían sin tomarse.
- Escribe las respuestas como alcance, restricciones y una definición de terminado comprobable, no en un documento aparte, sino dentro del propio ticket, donde la persona que vaya a construirlo realmente las verá.
- Trata la plantilla de arriba como punto de partida, no como norma rígida. Adáptala al lenguaje de tu equipo, pero no te saltes las preguntas. Si quieres el marco más amplio de por qué este paso de aclaración importa todavía más cuando los tickets vagos se entregan directamente a una IA, el primer artículo de esta serie explica el problema de alineación en detalle: Por qué la mayoría de las herramientas de IA para Jira empeoran el problema de alineación en lugar de resolverlo.
