Una lista de verificación de acceptance criteria que se queda en el elemento de trabajo

Acceptance criteria vs. Definition of Done vs. ready

Definition of Done es igual en cada story: tests, review, docs. Los acceptance criteria cambian con el trabajo — “el account owner puede exportar CSV en menos de cinco segundos”. Definition of Ready pregunta si esos ejemplos existen antes de empezar. La lista de verificación de pruebas QA es cómo los demuestras. Usar las tres como listas de verificación en el elemento de trabajo mejora la claridad y reduce la ambigüedad: el estado y los siguientes pasos se ven sin una búsqueda del tesoro.

Un ejemplo: una API que lista incidencias de Jira

Los acceptance criteria suelen diferir de una story a otra: cada lista describe lo que este elemento de trabajo debe entregar. Imagina un ítem de backlog que tu equipo podría tomar de verdad: construir un endpoint GET que devuelva una lista paginada de incidencias de Jira de un proyecto. Producto quiere campos y permisos claros. Engineering quiere paginación y formas de error acordadas. QA quiere algo que pueda demostrar con curl en una demo rápida.

La lista de verificación de abajo es lo que esa story podría llevar en el elemento de trabajo: no una plantilla para cada API, sino un patrón: quién puede llamarla, cómo se ve el éxito, cómo se ve el fallo y cómo mostrarías que funciona.

La mejor prueba de cada fila: ¿alguien puede demostrarlo sin adivinar? La siguiente story tiene su propia lista: la misma idea, ejemplos distintos.

Esa lista pertenece solo a esta story. En Checklist for Jira añades elementos así directamente en el elemento de trabajo, los marcas cuando aterriza el comportamiento y guardas una plantilla inicial breve cuando se repite la forma de las stories de tu equipo — con ejemplos nuevos escritos cada vez.

Guarda un arranque, edita por story

1. Checklist for Jira añade un panel Checklist en la vista de la incidencia. Añade ahí los acceptance criteria de tu escenario: usa el ejemplo de arriba como patrón y rellena filas para tu trabajo.
2. Si quieres un andamiaje reutilizable, guarda los encabezados (alcance, camino feliz, errores, listo para demo) como plantilla de proyecto o global y reescribe cada fila cuando empiece la siguiente story.
3. Puedes configurar automatización por plantilla para añadir ese andamiaje cuando se crea una Story o cuando el trabajo pasa a In Progress — o aplicarlo a mano desde Add → Add from template cuando lo necesites.
4. Si tu equipo quiere puertas estrictas en el proceso, añade un validador de finalización en una transición de workflow.
5. Resetea o actualiza elementos cuando cambie el alcance; combina con Definition of Done al final y la lista de verificación de pruebas QA cuando los testers posean un pase — véase la guía de automatización.

Combínala con el resto del set de entrega

Deja Definition of Done en la misma incidencia para el listón de envío. Adjunta la lista de verificación de pruebas QA cuando alguien necesite un pase de pruebas estructurado. Usa Definition of Ready en el refinement si la calidad de intake ayuda a tu equipo. Recorre el hub de plantillas para el conjunto completo.

Preguntas frecuentes