La plantilla clásica se ve simple:
Como [rol], quiero [acción], para [resultado].
El problema no es la plantilla. Es llenarla con niebla: “Como usuario, quiero una plataforma intuitiva, para tener una mejor experiencia.” Eso no se puede construir. No hay pantalla, no hay dato, no hay “listo”.
Una historia de usuario es un contrato corto entre quien pide el producto y quien lo arma. Si el developer tiene que volver a preguntar “¿esto incluye X?”, la historia todavía no está lista.
Los tres huecos que hay que llenar de verdad
Quién. Un rol del sistema, no “usuario”. Operador, cliente, administrador, dueño del negocio. Si dos roles hacen cosas distintas, son dos historias. Mezclarlos produce una pantalla que no le sirve a nadie.
Qué. Una acción concreta, en verbo de producto: registrar un pedido, ver el estado, aprobar una solicitud, descargar un reporte. Evita adjetivos (“ágil”, “moderno”, “completo”). El adjetivo no se programa.
Para qué. El resultado de negocio. No es adorno: recorta alcance. “Para no perder pedidos que llegan por WhatsApp” deja fuera un CRM entero. “Para gestionar la operación” lo deja todo dentro.
El criterio de aceptación no es opcional
Sin criterio, “terminado” lo define quien habla más fuerte. Con criterio, lo define un sí/no.
Escribe de tres a cinco condiciones observables:
- Dado un operador con sesión, cuando registra un pedido, entonces el pedido aparece en la lista del día.
- Si falta el teléfono del cliente, el sistema no deja guardar y dice qué falta.
- El cliente no ve la lista de todos los pedidos; solo los suyos.
Si no se puede marcar con un check, no es un criterio: es una intención.
Errores que retrasan al equipo
- Historias-épica. “Como admin, quiero gestionar todo el catálogo.” Eso es un módulo. Pártelo: alta, edición, baja, búsqueda.
- UI disfrazada de historia. “Quiero un botón azul a la derecha.” Eso es diseño. La historia dice qué logra la persona; el botón es una de las formas.
- Sin rol real. “Como el sistema, quiero enviar un correo.” El sistema no tiene necesidad. La historia es de quien espera el correo.
- Aceptación invisible. “Que se vea bien” o “que sea fácil”. Cámbialo por lo que una persona hace y ve.
Una historia lista para ticket
Cuando la historia está bien, el ticket casi se escribe solo: título, rol, criterio, y a veces la pantalla o el dato que toca.
Ejemplo:
Como operador de mostrador, quiero registrar un pedido con nombre, teléfono y producto, para no perder ventas que hoy se anotan en papel.
Listo cuando: (1) puedo guardar el pedido en menos de un minuto, (2) si falta el teléfono no se guarda, (3) el pedido queda visible en la lista del día.
Un developer puede estimar eso. Puede preguntar el formato del teléfono. No tiene que inventar el producto.
Dónde vive la historia
Si la historia queda en un slide, en un WhatsApp o en un Excel paralelo al tablero, deja de ser contrato. Tiene que vivir junto a los tickets, las pantallas y los datos — y actualizarse cuando el alcance cambia.
En Traductor Dev cada historia nace de un rol, se puede amarrar a tickets y a pantallas, y el criterio de aceptación viaja con ella. El developer no tiene que reconstruir el “para qué” desde el título del ticket.