¿Cómo escribes historias de usuario y criterios de aceptación?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Una historia es un marcador para una conversación: nombra quién quiere algo, qué quiere y por qué, para que el equipo juzgue el valor y piense en alternativas. Los criterios de aceptación son donde aterriza esa conversación: reglas concretas, ejemplos de entradas y salidas, quién puede hacerlo, qué pasa en caso de error y qué queda fuera. Los buenos criterios los lee el interesado y los ejecuta el tester sin más aclaraciones, y describen resultados y no los botones o tablas usados para alcanzarlos. Una historia que no puede entregarse y demostrarse en un sprint se divide por resultado, no por capa.

Ejemplo

Como responsable financiero, quiero exportar facturas aprobadas por rango de fechas para conciliar con el banco. Criterios: solo se incluyen facturas en estado aprobada dentro del rango inclusivo; el fichero tiene una fila por factura con número, fecha, cliente, neto, impuesto y total en la moneda de la cuenta; un rango sin facturas produce un fichero vacío con cabeceras; los usuarios sin rol de finanzas reciben un mensaje de permiso y ningún fichero; las exportaciones de más de 10.000 filas corren en segundo plano y envían un enlace por email.

Errores frecuentes

• Escribir la historia como una tarea del tipo añadir un botón de exportar.
• Dejar los criterios como la funcionalidad debe funcionar correctamente.
• Dividir una historia en piezas de base de datos, API e interfaz que por separado no entregan nada usable.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.