Anatomía de un Buen Ticket

La mayoría de los tickets son malos. Son títulos vagos — "arreglar bug de login," "actualizar dashboard," "trabajo de backend" — sin descripción, sin criterios de aceptación y sin contexto para nadie más que la persona que los escribió. Estos tickets crean la ilusión de seguimiento mientras en realidad no rastrean nada útil.

Un buen ticket tiene tres partes:

• Título como resultado. El título establece qué será verdad cuando el trabajo esté terminado, no qué actividad ocurrirá. "Los usuarios pueden restablecer contraseña por correo" es un resultado. "Trabajar en cosas de contraseña" es actividad. La diferencia importa porque los títulos orientados a resultados son verificables — puedes mirar el trabajo terminado y preguntar "¿esto es verdad?"
• Descripción como por qué. La descripción explica por qué este trabajo importa y proporciona suficiente contexto para que alguien no familiarizado entienda la decisión. No una novela — dos o tres oraciones que respondan "¿por qué ahora?" y "¿cuál es el impacto para el usuario?"
• Criterios de aceptación como qué. Una lista corta de condiciones concretas y verificables que definen "terminado." No "debería funcionar bien" — sino "el endpoint devuelve un 200 con un token válido, un 401 con credenciales expiradas y un 429 después de 5 intentos fallidos en 60 segundos."

La prueba para un buen ticket es la prueba de toma: ¿podría un ingeniero que no estuvo en la reunión donde se discutió esto tomarlo y entregarlo sin hacer preguntas aclaratorias? Si la respuesta es no, el ticket no está terminado — es un marcador de posición.

Los criterios de aceptación son la parte más omitida de un ticket y la más costosa de omitir. Sin ellos, "terminado" es lo que sea que el ingeniero que trabajó en ello piense que significa — lo cual puede no coincidir con lo que el product manager esperaba, contra lo que QA probará, o lo que el cliente realmente necesita.

Los buenos criterios de aceptación son concretos y verificables. "La búsqueda debería ser rápida" no es un criterio de aceptación — es una esperanza. "Los resultados de búsqueda se devuelven en menos de 200ms para consultas de hasta 1,000 registros" es verificable. "El formulario debería manejar errores con gracia" es vago. "El formulario muestra un mensaje de error en línea rojo cuando el campo de correo está vacío y el usuario hace clic en Enviar" es lo suficientemente específico para construir y verificar.

Los criterios de aceptación deben acordarse antes de que comience el trabajo, no escribirse después. Cuando un ingeniero y un product manager se alinean en los criterios antes de la primera línea de código, se están alineando en el alcance. Sin esa alineación, el ingeniero construye lo que entendió, el PM esperaba algo diferente, y el ticket rebota — costándoles tiempo a ambos y erosionando la confianza. Escribir criterios de aceptación por adelantado toma 10 minutos. Rehacer una funcionalidad mal entendida toma días.

La descripción es la fuente de verdad. Los comentarios son la conversación al respecto. Mezclarlos es cómo los tickets se vuelven ilegibles.

La descripción debe contener todo lo que alguien necesita para entender el trabajo: el contexto, los requisitos, los criterios de aceptación y cualquier enlace relevante. Se escribe una vez (y se actualiza si el alcance cambia). Es la parte que lees primero cuando tomas un ticket, y debería responder tus preguntas sin requerir que te desplaces por 47 comentarios.

Los comentarios son para la discusión que ocurre durante el trabajo: preguntas aclaratorias, negociaciones de alcance, actualizaciones de estado, retroalimentación de revisión. Los comentarios son de solo agregar y cronológicos — capturan la conversación, no la conclusión. Cuando un hilo de comentarios resuelve una pregunta que cambia los requisitos, la respuesta vuelve a la descripción. La descripción se edita; el comentario permanece como el registro de auditoría de cómo se llegó a la decisión.

Los equipos que vierten todo en comentarios terminan con tickets donde los requisitos reales están enterrados en el comentario #23, intercalado entre una actualización de estado y una reacción emoji. El ingeniero que toma el ticket tiene que leer todo el hilo para reconstruir el estado actual. Eso no es coordinación — es arqueología.