Validador automático de tickets Jira que mató el cuello de botella del refinement

Contexto

Departamento de producto/tecnología de tamaño medio. Cuatro squads trabajando en paralelo con un backlog compartido en Jira. La regla era: "antes de refinement, el ticket tiene que tener criterios de aceptación, mockup si aplica, dependencias identificadas y owner". La realidad era que el 40% de los tickets llegaban a refinement con campos vacíos.

El patrón típico: alguien creaba el ticket un martes, nadie lo miraba hasta el viernes (refinement), el viernes se descubría que faltaba la mitad de la información, había que pedírsela al autor, el autor estaba en otra reunión, el ticket se iba al sprint siguiente. Resultado: el sprint planning del lunes empezaba con menos tickets refinados de los necesarios.

El desafío

• Validar al crear, no al refinar. El problema no era la falta de información, era detectarla días tarde. Necesitábamos validación en tiempo real.
• Sin cambiar las plantillas de Jira. El cliente había iterado durante años sus templates y no quería tocarlos. La validación tenía que vivir fuera de Jira.
• Sin añadir más reuniones. Cualquier solución que implicase "ahora tenemos una reunión nueva los miércoles" estaba descartada.

Aproximación

Webapp interna desplegada en la infraestructura del cliente, conectada a la API de Jira vía webhooks:

1. Discovery (1 semana). Revisión de 200 tickets históricos para identificar patrones de "tickets malos": criterios de aceptación vagos, dependencias no mencionadas, mockups ausentes, owner sin asignar, tamaño no estimado. Salieron 9 reglas de validación.
2. Webapp de validación (semanas 2-3). Aplicación construida sobre la infraestructura del cliente que se suscribe a webhooks de Jira. Cada vez que se crea o modifica un ticket, ejecuta las 9 reglas en menos de un segundo. Si encuentra problemas, marca el ticket con una etiqueta y comenta automáticamente con un checklist concreto: "Falta criterio de aceptación. Falta tamaño. Falta dependencia con X módulo (detectada por mención)."
3. Notificación al autor (semana 4). Integración con Slack: si el ticket sigue marcado tras 24h, el autor recibe un DM con el checklist y un botón "marcar como completado" que vuelve a ejecutar validación.
4. Dashboard de calidad de backlog (semanas 5-6). Panel interno con métricas: % de tickets que entran limpios, autores con mayor ratio de tickets marcados, reglas que más fallan. Para los Product Managers, no para hacer leña a nadie, sino para detectar dónde formar al equipo.

El stack: webapp interna con asistencia de desarrollo IA-first, API de Jira, integración con Slack, base de datos interna para el histórico. Todo desplegado en la infraestructura del cliente, ningún dato salió.

Resultados

• ~70% reducción de re-trabajo medido como tickets que volvían al autor desde refinement (de un 40% inicial a un 12% final).
• Refinements que duraban 90 minutos pasaron a durar 50, porque dejaron de gastar tiempo en "esto no se entiende".
• Sprint planning empezó con backlog refinado completo de forma sostenida desde la semana 6.
• Métricas de calidad de backlog disponibles por primera vez para los PMs, sin necesidad de extraer datos manualmente.
• 0 reuniones nuevas introducidas. Toda la validación ocurre en background o vía Slack asíncrono.

Aprendizaje aplicable

El cuello de botella en muchos equipos de producto no es la velocidad de desarrollo. Es la latencia entre que alguien escribe un ticket y alguien detecta que el ticket está incompleto. Esa latencia es donde se evapora la velocidad real del sprint.

La pieza más infravalorada del proyecto no fue la validación automática, fue el dashboard de calidad de backlog. Una vez los PMs vieron qué autores creaban tickets que siempre fallaban en la regla "criterios de aceptación", pudieron hacer 1:1 formativos específicos. La herramienta no sólo limpia tickets, formó al equipo.

Aprendizaje técnico: las validaciones agresivas (las que bloquean al autor) generan rechazo cultural. Las validaciones que marcan y avisan sin bloquear son mucho mejor acogidas y dan el 90% del valor.

Nota sobre confidencialidad

El nombre del cliente está omitido por acuerdo de confidencialidad. Las cifras son reales o estimaciones conservadoras basadas en mediciones internas del propio cliente.